I follow instructions in README file, use 'git flow init' instead of 'git init' and get fatal errors (RHEL5):

$ git flow init

fatal: Not a git repository
fatal: Not a git repository: ''
fatal: Not a git repository: ''
fatal: Not a git repository: ''
fatal: Not a git repository: ''
Not a git repository

$ git flow help init

fatal: Not a git repository
fatal: Not a git repository: ''
fatal: Not a git repository: ''
fatal: Not a git repository: ''
usage: git flow

Available subcommands are:
init Initialize a new git repo with support for the branching model.
feature Manage your feature branches.
release Manage your release branches.
hotfix Manage your hotfix branches.
support Manage your support branches.
version Shows version information.

Try 'git flow help' for details.

This could be implemented using an optional "-k / --keep" flag, like so:

git flow feature finish -k foo

Not removing the feature branch after a successful merge in develop makes it easy to undo the merge, simply by removing the merge commit. On develop, such an undo would look like:

git reset --hard HEAD^

When I start a release branch:

$git flow release start release-1.1 1fe0166
Switched to a new branch 'release/release-1.1'

Summary of actions:
 - A new branch 'release/release-1.1' was created, based on '1fe0166'
 - You are now on branch 'release/release-1.1'

 Follow-up actions:
 - Bump the version number now!
 - Start committing last-minute fixes in preparing your release
 - When done, run:

      git flow release finish 'release-1.1'

I want to follow up and bump the version nmber. But why and how? Is it done automagically when I do finish ?

very often it is required to do not only some changes before the release, but also afterwards. For example (I'm sure that there are many other use cases where "after-processing" is required): developing in java with maven you have to push the version before a release. Afterwards you have to change it to the next version as a snapshot: e.g.:

1.0.0-SNAPSHOT -> 1.0.0 -> 1.1.0-SNAPSHOT

The problem with the current git-flow workflow is that you have to do these changes directly in the development branch. IMHO it will be much clearer in the history if you would do something as the following:

$ git flow release start 1.0.0
--bump version from 1.0.0-SNAPSHOT to 1.0.0
--do other changes
$ git flow release finish 1.0.0 --master
--this will merge the release/1.0.0 into the master and tag it; but do not kill the branch
--now i can change the version from 1.0.0 to 1.1.0-SNAPSHOT
$ git flow release finish 1.0.0 --develop
--finally merge the release/1.0.0 branch into the dev branch and delete the branch

IMHO this will really help :) WDYT?

Shell scripts are a little bit hostile towards Windows developers. Any plans?

Now you have to manually do git stash, git flow feature start foo, git stash pop each time. Annoying.

$ git flow track feature xxx
Branch 'origin/feature/xxx' does not exist and is required. <— First run gives an error
$ git status

On branch master

nothing to commit (working directory clean)
$ git branch -a
develop

• master
  origin/develop
  origin/feature/xxx <— It is available!
  origin/master
  $ git flow track feature xxx
  Branch feature/xxx set up to track remote branch refs/remotes/origin/feature/xxx.
  Switched to a new branch "feature/xxx"

Summary of actions:

• A new remote tracking branch 'feature/xxx' was created
• You are now on branch 'feature/xxx'

Expanding git-flow is becoming increasingly tedious. The subcommand structure isn't flexible enough to support heterogenous subcommand styles and flag parsing is a pain in the ass to get right on all platforms.

Also, there is a lot of duplication in the code already because of limitations in the way sh forces you structure your code.

This calls for a total reimplementation in a higher-level language of choice. That will be Python. Since the project is still rather small, this should not be too big an issue.

I get this:

git flow feature finish -F fix_payment_method_creation
No branch matches prefix '-F'

Tried putting the -F option in all positions but no luck. I am hoping this will delete the remote branch. Am I doing something wrong?

[nvie@cru:/home/driev00/ad] feature finish RFC124
Branches 'develop' and 'origin/develop' have diverged. 
And local branch 'develop' is ahead of 'origin/develop'. 
Switched to branch 'develop' 
Your branch is ahead of 'origin/develop' by 3 commits. 
Auto-merging CHANGES 
CONFLICT (content): Merge conflict in CHANGES 
Automatic merge failed; fix conflicts and then commit the result. 
mkdir: 0653-357 Cannot access directory /. 
/: The file access permissions do not allow the specified action. 
A file or directory in the path name does not exist. 
/home/nvie/gitflow/git-flow[24]: /.gitflow/MERGE_BASE: 0403-005 Cannot create the specified file.

Apparently, the variable DOT_GIT_DIR is unavailable in that environment. Happens on line http://github.com/nvie/gitflow/blob/develop/git-flow-feature#L297

Look into this further.

Take care of the situation where two release branches live next to each other. In that situation, a "finish release" action should merge back changes into the other release, not into 'develop'. Or at least warn about it. Or not support creating a new release branch if the other isn't finished yet.

I know that git flow is useable on Windows with Cygwin, but is there a reasonable way to use it in MSysGit? I've gotten very fond of Git Bash...

Feature branches should be merged into develop using the --no-ff option, correct? I just closed a feature, and it merged in with a fast-forward:

Jeremy-Bushs-MacBook-Pro:Vendo jeremybush$ git flow feature
checkout-process

• The feature branch 'feature/user-admin' was merged into 'develop'
• Feature branch 'feature/user-admin' has been removed
• You are now on branch 'develop'

You can see the tree for this here: http://github.com/zombor/Vendo/network

The adding manage my account for logged in users commit should have been merged from the feature branch with the --no-ff flag.

I'm using 0.4-dev.

In order to ease the maintaience work, it will be nice to add web interface in front of the command line

In web gui, it can provide

• click the button to manage the work flow
• visual the model tree in web (it is the comment from Ken Barker in Jan 21st on the blog)

Corrupt install on RHEL5 (CentOS 5.4)

install -d -m 0755 git --exec-path 2>/dev/null || echo /usr/libexec/git-core
install -m 0755 git-flow git --exec-path 2>/dev/null || echo /usr/libexec/git-core
install -m 0644 git-flow-init git-flow-feature git-flow-hotfix git-flow-release git-flow-support git-flow-version gitflow-common gitflow-shFlags git --exec-path 2>/dev/null || echo /usr/libexec/git-core
install: cannot stat `gitflow-shFlags': No such file or directory
make: *** [install] Error 1

There is no need to install gitflow in GIT_EXEC_PATH. It would be absolutely OK to install
in e.g. /usr/local/bin by default.

Background: I have the latest git version always installed in /usr/local/git-VERSION with a symlink
as /usr/local/git. Doing the normal 'make install' would put gitflow in /usr/loca/git-VERSION/bin forcing
me to reinstall gitflow when updating git.

I just installed git-flow by hand and

git flow init -f

returns

flags:WARN getopt: option invalide -- 'f'
-- 'init'
flags:FATAL unable to parse provided options with getopt

I don't know if it is an shFlag issue or git-flow one. I launched the shFlag/bin/gen_test_results.sh and it failed only on:
'public' test suite:
testEnhancedHelpOutput

Any volunteers?

For those of us on shared hosting....

Using Ubuntu 10.04 and code from develop branch (4de01f2)

$ git flow init -f
flags:WARN getopt: option invalide -- 'f'
 -- 'init'
flags:FATAL unable to parse provided options with getopt.

Just installed gitflow under Cygwin (using zsh). When I git flow init the repository I first got the following error:
flags:FATAL unable to determine getopt version

I needed to install the util-linux package which got me getopt (enhanced) 1.1.4 and was a bit difficult to find in Cygwin's package list. Perhaps this could be added to the readme.

Now with getopt in place I still cannot initialize the gitflow repository. The new error messages read as follows:

$ git flow init
flags:ERROR flag name (help) is reserved
flags:FATAL unrecognized option (,)

When attempting to use the message flag for finishing a release I am getting an error.

Here is what I attempted to run:

git flow release finish 0.1.3 -m 'Releasing version 0.1.3'

And here is what it returns:

flags:WARN getopt: invalid option -- 'm'
 -- 'release' 'finish' '0.1.3' 'Releasing version 0.1.3'
flags:FATAL unable to parse provided options with getopt.

Running the latest from the develop branch.

I think git flow init should set master and develop branches to track correspondent origin branches if they are avaiable. I find myself creating them by hands with --track option instead of git flow init.

It would be great to have the ability to do something like git flow release delete v1.0.2, instead of git checkout develop && git branch -D release/v1.0.2 (which I'm not even sure correctly discards a release branch) and hoping no important steps were missed.

Update readme regarding installing Cygwin package System/util-linux to make gitflow work.

Error:

$ getopt
bash: getopt: command not found

Pretty self-explanatory ;-). Because of that it's unusable after install.

The branch master exists. Even git flow init says it. But it says it doesn't exist anyway.

rees@tardis ~/pyd $ git flow init

Which branch should be used for bringing forth production releases?
   - PY_3X
   - gh-pages
   - master
Branch name for production releases: [] master
Local branch 'master' does not exist.

This is on Gentoo with git version 1.7.1 and git flow version 0.4-dev.

I just tried installing your git-flow solution and I am getting the following error.

git flow feature
/usr/local/git/libexec/git-core/git-flow: line 57: /usr/local/git/libexec/git-core/shFlags/src/shFlags: No such file or directory

I am guessing this might be related to the submodule you recently added?

Let me know if you have any ideas on how to fix this problem.

Thanks!

I would like to use ~/.gitconfig to setup defaults for gitflow. It seems to partly work for branch prefixes but ignored for develop and master branches.

I have next .gitconfig setup:

[gitflow "branch"]
master = master
develop = work

[gitflow "prefix"]
feature = feature/
release = release/
hotfix = hotfix/
support = support/
versiontag = v

Here is git flow init output:

 git flow init
Initialized empty Git repository in /Users/mk/test/git/gitflow3/base/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master] \c

Branch name for "next release" development: [develop] \c


How to name your supporting branch prefixes?

I think it should suggest options from .gitconfig.
Also it shows only question line for prefixes, but don't give chance to change or see them.

trying the following command results in an error:

git flow init
flags: FATAL unable to determine getopt version

There is no command called getopt in the latest cygwin, there is an internal command getopts though.

Right now the git-flow-release script only creates 'light weight' tags.
It would be nice to be able to configure creation of annotated of even signed tags.

Quick braindump

Its purpose is much like "tracking" a remote peer's feature, to work on it together and share commits, passing by the origin repo until it's finished.

git flow feature clone <remote> <name>

For example, Alice has a feature called "refactoring" and wants Bob to run a peer review on it. Then, Bob fetches Alice's branches (given he has read access in Alice's repo). He receives a remote branch now called "alice/feature/refactoring". To do this, he calls:

git flow feature clone alice refactoring

he should get a local branch called feature/refactoring, that is based on alice/feature/refactoring, but is not tracking that in the Git sense (because a subsequent git push will not have commit access to Alice's repo and will therefore fail). The clone action:

• fetches Alice's branches (git fetch alice)
• creates a local feature branch based on Alice's feature branch if that feature branch does not exist locally; or
• merges Alice's branch into the already existing local feature branch
• checks out that new branch

Then Bob commits his peer review comments and tells Alice to fetch again. Alice does the same thing on the other side, then:

git flow feature clone bob refactoring

Implementation detail

If we add an optional flag to this command called --track, we can replace the git flow feature track <name> subcommand implementation by a call to git flow feature clone --track origin <name>.

Discussion

I'm not quite happy with the name of the subcommand yet. To avoid confusion with the git clone behaviour, I think the final name should be something different. Maybe something more general like "update"? Also I think it would be nice to make no distinction between the situation where the local feature branch does not yet exist (i.e. "branch"-like) and the situation where it does already exist and you want to update (i.e. "pull") Alice's (or a third person's) changes in again.

This results on ubuntu with git flow init resulting in:
mib@mib-netbook:~/test$ git flow init
/usr/lib/git-core/git-flow: 78: typeset: not found
Unknown subcommand: 'default'
usage: git flow init

Modifying git-flow to use /bin/bash instead of /bin/sh fixes this for Ubuntu, but might break more sensible OS's.

For example:
$ git flow finish feature --rebase xxx

Origin repositories should be optional, always. There should be no situation anymore in which git-flow nags about it not existing.

It's been mentioned in the original blog post's comments section, and on this thread: the current way releases are finished merge the release branch into master and develop, but does not record a relation between them, which makes git-describe output very inconvenient (if not to say very confusing :)).

For example: consider the case where you have a version 1.0 tagged, then finish a new 1.1 release. When using git-describe, it scans the commit tree upwards, and finds 1.0 as the first tagged commit, generating a misleading identifier somewhat like 1.0-52-g25def71, instead of something like 1.1-8-25def71.

This requires a change to the original branching model, too.

I keep my homedir in git (dotfiles, anyway), so everything in ~/git thinks it's unstaged, which means when I type git flow init in ~/git/new-repo, it fails. I tried git flow init -f but got

flags:WARN getopt: invalid option -- 'f'
 -- 'init'
flags:FATAL unable to parse provided options with getopt.`

Hi. I'm writing a zsh completion plugin for git-flow. http://github.com/chevalun/git-flow-completion

It's usable now, but contains a annoying bug.

For now, if the feature list is empty, git-flow will return a hint like this

No feature branches exist.
You can start a new feature branch:
git flow feature start []

But it's different for a script or a program to handle an error report like this, since it is the only API.

If returning a non-zero value when feature, hotfix, release list is empty, then it is more convenient for programmers writing programs based on git-flow.

Or maybe output the hint to stderr. I'm not sure if it is a good idea.

I proposed dropping the "flow" command for start/finish tasks and using optional arguments and defaults instead of feature/release/hotfix/support.

Instead of

git flow start [type]
git flow finish [type]

use

git start [type]
git finish [type]

The type could be specified using options:

-f/--feature
-r/--release
-h/--hotfix
-s/--support

When calling git-start, -f is assumed. E.g.:

git flow start feature <name> => git start <name>
git flow start hotfix <name>  => git start -h <name>

git-finish would look at the current branch name to guess which type of branch you're finishing. But you can pass -f/-r/-h/-s to override the default convention.

This forum post proposes the use of "-s resolve" for merge/rebase to work around the bug.

Currently when starting a new feature/etc on a 'dirty' working directory it shows a message:

fatal: Working tree contains unstaged changes. Aborting.

What if we changed that functionality do to a git stash of the before creating the branch, create the new branch for the feature/etc, then git stash apply after switching to the new branch?

This happens just before the end of the operation

[...]
create mode 100644 web/js/frontend/play.js
local: 1: release/0.6.0: bad variable name
M   plugins/wkToolkitPlugin
Switched to branch 'develop'
[...]

I did create a local feature branch manually, based on a remote feature branch (peer/feature/RFC132), which set up tracking. Then, when finishing-by-rebasing the feature branch succeeds, git-flow tries to remove the feature branch, but Git nags about it not having been pushed back into peer/feature/RFC132.

Output:
[nvie@cru:/home/nvie/ad] feature finish -r RFC132
Branches 'develop' and 'origin/develop' have diverged.
And local branch 'develop' is ahead of 'origin/develop'.
Will try to rebase 'RFC132'...
Current branch feature/RFC132 is up to date.
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 16 commits.
Merge made by recursive.
CHANGES | 1 +
src/modules/j2calias.py | 13 ++++++++++---
2 files changed, 11 insertions(+), 3 deletions(-)
warning: not deleting branch 'feature/RFC132' that is not yet merged to 'refs/remotes/peer/feature/RFC132', even though it is merged to HEAD.
error: The branch 'feature/RFC132' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature/RFC132'.

Say that you start working on a feature (xyz) and need to jump off to do a hotfix or work on another feature or something. Right now I am simply committing where I am with the current feature, starting a new git flow hotfix and then doing a git checkout feature/xyz. I BELIEVE this is correct but since Ive been trying to stick to the whole "git flow" thing I think it makes sense to have a "git flow release/feature/etc continue" or "git flow release/feature checkout" or the like

Thoughts?

$ git flow init
...
$ git flow start feature xxx
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
Remote branch 'origin/develop' does not exist and is required.

I wonnder why bugfix branches are missing in git flow. I think they are the same as features but with different prefix. Are they supposed to live in develop branch as commits without special branches?

It would be kind of cool if the git-flow config could optionally include the path to a script for automatically invoking a version-bumping script. That way, as soon as git flow release start v0.2.3 is typed in, the version bump happens and can be committed on the new branch immidiately, to lessen the chances of forgetting.

Of course, callbacks like this will be much easier to implement when git-flow is converted to Python, per #33, and might be better served as general event callbacks, instead of being specific to "version-bumping", so that I could tell git-flow to execute a script after git flow release start and the same script after git flow hotfix start.