In Summary

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.

General Workflow

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.

First, 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).

Using 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

Note the 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.