The git flow extension adds wrappers to support the (very good) nvie branching model . I recommend first reading Why aren’t you using git-flow? before getting here. This is not a user guide but instead is a list of things that caught my attention.
Using git aliases, the commands are significantly easier. I find
git flow to be very verbose and easy to forget the order of the commands. As example,
git flow feature start $name seems backwards to me. Since I have trouble remembering the order, I use a git alias.
In my own experience and belief, the long running “next release” branch is what they call
develop. I dislike this. I believe the long running branch should always have completely functional and complete code in it.
Due to this, any work of any consequence should be done in a feature branch. Fortunately, feature branches are cheap and easy to create.
If it is fixing something that slipped through the cracks, configuration or unit test fixing then committing directly to the
develop branch makes sense. Anything more than that should go into a feature branch.
The reason for this belief is that by having something feature incomplete or broken in
develop can cause other developers consternation or confusion. This introduces friction into the development environment and slows things down. Decisions should be made to limit friction in the environment.
Unexpected Behaviors: Remotes are left out.
git flow does not do any remote modification on its own. You have to explicitly do so. I recommend creating aliases for the commands to help track this.
This also includes the shared ‘staging’ and other long-life branches. The first thing to do after
git flow init on a repository is:
git push origin staging:refs/heads/staging git fetch origin git config branch.staging.remote origin git config branch.staging.merge refs/heads/staging git checkout staging
(Commands above taken from
grb explain publish staging)
This allows proper remote tracking of the staging branch.
As a matter of Good Practice, not having remote branches is silly. For certain things I would expect that to be acceptable but it’s a shame to hide your work. Rejoice in the code you write and let others rejoice (or make fun of you).
git flow in combination with
grb is best. When you create a feature branch with
git flow feature start $name you should then do
grb publish $name.
Aliases for git-flow and grb.
[alias] # fs, feature start fs = !git flow feature start $1 && grb publish feature/$1 # ff, feature finish. Always push to the final branch (remote) # if it was successful ff = !git flow feature finish $1 && git push
feature/ above. If you changed your feature branch prefix you’ll need to change this. I’m sure there is some fancy git way to do that automatically.