GitFlow "broken" on v


after upgrading to v I get this whenever starting a new feature (test in this example):

git flow feature start test

git: 'flow' is not a git command. See 'git --help'.

Did you mean one of these?



The repo has been initialized before and worked with previous version (click-once btw)

I get this on a fresh repo when trying to init GitFlow:
git flow init -d
git: 'flow' is not a git command. See 'git --help'.
Did you mean one of these?

2 answers

1 accepted

1 vote
Accepted answer

We did change how git-flow was located in 0.9.3, in order to fix a couple of problems with the 'rebase' option of finishing features and releases, however I've tested this on a couple of machines without any issues, using both the system Git install and embedded Git install. Both init and other functions appear to work fine.

The change was that instead of directly calling the git-flow script, we add its location to the PATH, which allows it to call itself. The location is %USERPROFILE%\AppData\Local\Atlassian\SourceTree\gitflow_local, can you check if that exists for you? If it does, can you confirm the full path?

No, that location is not in my PATH.
However, I added this manually %USERPROFILE%\AppData\Local\Atlassian\SourceTree\gitflow_local\gitflow and that seemed to do the trick.

Sorry, I actually meant that SourceTree adds this to the PATH of the git process when it calls it - it doesn't alter your global PATH. It's interesting that adding this to your PATH worked though, that makes me wonder if your PATH is already quite long or something like that which is stopping the SourceTree addition to the git processes PATH from working?

Ah, ok got it. No my Path ain't that long. It's not a permission issue?? Also, note that the location I added wasn't the same as you posted but that might have been a typo on your side perhaps!?

Sorry, I forgot to add the subfolder to the path I listed above. I'm not sure why adding it to your global PATH is any different to us adding it to the git process PATH, the latter seems to be fine here and any permissions should apply both ways.

What I've done instead for the next version is to use a middle ground where we call the git-flow script explicitly (like we did in, but *also* add the gitflow scripts to the git processes PATH to resolve the recursive call issues that came about from using the 'rebase' option. Hopefully that should resolve your issue since the former worked for you before, while also solving the problem that had been raised by others.

Same here: fit flow does not work anymore after updating...

Trying to perform a hotfix results in:

git flow hotfix start TST1
bash.exe: warning: could not find /tmp, please create!

/bin/sh: C:\Users\xxx\AppData\Local\Atlassian\SourceTree\gitflow_local\gitflow\git-flow: No such file or directory

fatal: 'flow' appears to be a git command, but we were not
able to execute it. Maybe git-flow is broken?

Completed with errors, see above.


* Which tmp is being looked after?

* C:\Users\xxx\AppData\Local\Atlassian\SourceTree\gitflow_local\gitflow\git-flow exists for sure on my machine ...

Updating to SourceTree 0.9.4 resolves my issues described above

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Friday in Agile

Are you a Jira Service Desk agent? We want to talk to you!

Are you a whiz at handling tickets and looking at how you can further optimize your workflow with automation? Do you tackle detailed customer support questions while simultaneously getting flooded wi...

93 views 0 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you