Git Workflow With Capistrano

Question

I\'m trying to get my head around a good git workflow using capistrano. I\'ve found a few good articles, but I\'m either not grasping completely what they\'re suggesting (likel

Answer 1

The way that I do it is to have a 'staging' branch that is tracked on your blessed repo. You will want to use the gem 'capistrano-ext' which provides a few extra config options for stages (I think you are already using this considering your call to deploy on staging). capistrano-ext defines stages, which allows you to have a deploy file for each stage, eg 'staging' where you define the branch set :branch, "staging" unique to each stage you are deploying to. You can do your workflow above and add:

#after commiting on bug-fix branch
git checkout staging # => tracks staging on origin
git merge bug-fix-branch # => bring new code in
git push origin staging # => capsitrano acts locally, it needs the code to get from origin
cap staging deploy # => wasnt that easy?

in an ideal world, you also have a production branch, thus the git branches become agreed upon by the team as

• master - edge code where the team shares between devs
• staging - code to be tested by the client on a staging server (fast-forwards on master merge)
• production - stable release (fastforwards from staging)

EDIT: the response to the comment was too long so i had to append to the answer.

You have several ways to deal with this, I can think of one right away. A fix on prod needs to be reflected in all branches asap so your devs are working on the same base. Assuming prod has a direct common ancestor to staging, and staging to master, a fix on prod should be added to a topic branch based off the HEAD of the prod branch, then merge that change with master and then into staging and finally for deploy into production. The idea is that the only diff is the commits for the bug fix, next time you fast-forward production to the head on staging, you would already have the object that represents the change from the prod bug you fixed, so there is no problem (and since there is good testing for the bug you know it works, after running the suite on each branch). Otherwise you would probably have to cherry-pick a commit from master and apply to prod and staging. Take a look at pro-git.org for more advanced workflows like that.