I think that some of the workflow from the git git repository is a
great model.  The relevant bit for you is that there are four primary
branches - master, maint, next, and pu - and that releases are tags,
not branches.
* master is totally stable, working toward the next release, which
will be a tag along this branch.
* maint is maintenance, and is regularly merged into the other
branches.  Maintenance releases will be tagged along this branch.
* next contains stable but not totally proven changes which should
eventually be merged to master.
* pu contains unproven proposed changes, which will hopefully be
merged to next at some point.

Using tags instead of branches avoids changing branch names every time
you have a release, and the branch names will help you keep your
development in good order.  Something you might modify here is to have
a maintenance branch for each past release (like v1.x) and keep that
branch around as long as that version is being maintained.  You just
have to be careful to merge all of them upward - v1.x into v2.x and
v2.x into master, for example.  You can also mess around with the
number of classes of stability/tested-ness.  The important bits are
using tags, and using constant names like master and maint.

This won't modify the commands you mentioned using.  I don't know
anything about Capistrano, but long as it's just grabbing from the
master branch, it won't change.  It will require pushing more branches
to github, but that's just extension of what you're already doing.

If you're curious about the git git workflow, there's a description of
it within the repo, accessible from gitweb.  It's obviously a way
larger scale than what you're doing (or what I do), but it's well-
written and got me to make sure I was thinking about things.


On Jul 20, 5:37 pm, Ken <kohud...@gmail.com> wrote:
> Hi All,
> I am close to deploying version 1.0 of a new Ruby on Rails
> application.  I am a single developer (no team complications) and I
> have been using Git and Github as follows:
> a.  Make changes to source code and commit to local git repository
> (branch = master).
> b.  Push the changes to github with this command:  "git push origin
> master"
> c.  Use Capistrano to deploy changes to the staging server using
> github as the repository.
> d.  Repeat the above steps for each change.
> Now that I am close to deploying version 1.0 to production I have been
> trying to figure out an appropriate workflow.  Would the following
> work:
> a.  Make any final changes and push the changes to the local git
> repository (branch = master).
> b.  Push the changes to github with this command:  "git push origin
> master"
> c.  Use Capistrano to deploy changes to the production server using
> github as the the repository..
> d.  Create a new branch called "release2" in the local git repository.
> e.  Continue development of Release 2.0 code in the release2 branch.
> f.  If a bug fix is required to version 1 code, commit the changes to
> the master branch in the local git repository, do a "git push origin
> master" and deploy from the github master branch to production.  Also,
> merge the changes into the release2 branch.
> g.  When release 2 is done, merge the release2 branch into the master
> branch and deploy from master.
> Or, is there a better way to do what needs to be done?
> I would sincerely appreciate any ideas or suggestions.
> Thank you and best regards, Ken
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to