How to convert existing git repository to use git-flow?
Run git flow init from the repository folder just like as you would do for new repository
Can I still do manual branches and merges when I use git-flow?
Of course you can.
git-flow does not forbid you to keep using vanilla Git commands!
So if you want to merge
develop for whatever reason you want
to, you can safely do so without breaking
git-flow compatibility. Do you
want to manually merge a feature branch X into another feature branch Y? Not
a problem. As long as you do it consciously and realize what this means for
finishing those branches later on.
Why does git-describe not work for me?
When finishing release and hotfix branches, that branch's HEAD is first merged into
master and then into
develop. It is not the resulting new
merge commit from
master that is merged back into
develop. This means
that a linear path from the new
develop branch to the new
is not created. Even worse, a linear path is created from the new
branch to the previous
master commit. Although unintended, this is
simply an effect of using the current branching rules.
git-describe in these cases, you can get very confusing and
misleading results, since
git-describe scans the current commits linear
history for the most recent tag it finds, which will always be the previous
If your project uses Maven, then buildversion-plugin may be your ticket.
I will change this behaviour in the next version of the branching model explicitly and I will include this behavioural change in the first version of the Python rewrite.
For more references to this problem, see:
Can I use it with Windows?
There have been reports of Windows users using
Unfortunately, I have no Windows environment to test it on, but
this issue should be
helpful in setting it up. And see this FAQ page for Windows installation instructions.
How does it integrate with Gerrit?
Git flow is not aware of gerrit, but since by default all its operations are on the local repository, it is perfectly safe to use with gerrit. You need to create the "develop" branch physically in gerrit (it has a UI for branch management), and all team members need to have permission in gerrit to push tags and also to create and delete branches if they want to share work on features and releases. The only awkward thing is that
git flow release finish results in a tagged commit on master that has no gerrit change id. It's easy to fix: just
git commit --amend and then push it to gerrit as normal - the commit should be empty, so it doesn't require a review, but gerrit has to have it with its proper change id. Also beware of tools (e.g. git review) that want to rebase automatically before pushing to gerrit - it's fine for normal development work, but switch that off before pushing merged releases.
What is the 'support' branch?
It's an experimental feature that is currently being worked on. When you try using it you'll get warnings telling you not to use it in production. It essentially allows you to fork master, but once it's forked it stays forked. It has been speculated (on the blog) that it is useful if you have a client that has a very specific request which you wouldn't ever want to use outside of that one client's version of the project. I imagine we will hear more about it when it's ready.