I read the info at the following link, but I am still confused.
OS: Windows 7 64 bit
Sourcetree: version 184.108.40.206
System Git: version 1.8.4
The following error is reported by sourcetree when I try to create a feature branch using git flow.
sh.exe C:\Users\sdfox\AppData\Local\Atlassian\SourceTree\gitflow_local\gitflow\git-flow feature start feature5
fatal: Not a gitflow-enabled repo yet. Please run "git flow init" first.
Completed with errors, see above.
So I open up a terminal and run git flow init but I get an error that "git: 'flow' is not a git command. After reading some other articles, I started searching around. I could not find any kind of program within the /usr/bin/ directory that seems related to git flow. I am now wondering if it wasn't part of the installation. Is this a git issue or a source tree issue? I'm not sure where to go from here, so I would appreciate any advice. I do have both a master and dev branch that track the remote branches. If there is any other info that I can provide, just ask. Thanks in advance!
Have you initialized the repo with git-flow support using the option in the UI? You have to do it manually before start using git-flow commands in SourceTree.
SourceTree does not install git-flow globally on your system. If you want to access it directly from command line, the path should be %USERPROFILE%\AppData\Local\Atlassian\SourceTree\gitflow_local but I don't have a running win VM now, so I can't confirm that's still there in the latest version...
You can also add it to your PATH variable.
But if you plan to use Git Bash regularly, I recommend you to install git-flow in your MsysGit environment. Another (extreme) recommendation is to NOT use the nvie git-flow version that SourceTree uses, as it's somewhat buggy and is not actively maintained anymore.
I regurarly use this fork: https://github.com/petervanderdoes/gitflowIt's more powerful, stable, and actively developed. In windows u must use it at the Git Bash, but on OSX you can tell SourceTree to use your version of git-flow instead of the embedded one, and sooner or later the same option will come up in win version too (I hope).
"Have you initialized the repo with git-flow support using the option in the UI? You have to do it manually before start using git-flow commands in SourceTree."
Within SourceTree, if I select < Repository, Git Flow >, then the Initialize Repository option is already grayed out. In my mind, that means that it has already been done. Yet the GUI still tells me that I need to do it when I try to begin a new feature.
I setup an alias to the path that you mentioned. git-flow is in fact located there. Thank you for pointing that out. I setup an alias to quickly run it. The result was a different error "flags:FATAL unable to determine getopt version"
Yes, the git-flow command in MsysGit requires some libs to be in place to work. See https://github.com/nvie/gitflow/wiki/Windows#wiki-msysgit
If you really want to use git-flow at the git bash, I strongly recommend you to install a fresh copy using the instructions in the link above. If you plan to use git-flow BOTH in the command line and in SourceTree, then use the nvie code in the above link. If u want to use ONLY in the command line, install the fork I pointed out in my original answer.. it works (far) better, but you should pay attention to NEVER use the GUI anymore to issue git-flow commands.
Regarding your repo, close SourceTree, then open the "config" file under the .git directory, and delete the sections that start with [gitflow ...] (for example gitflow "branch" and gitflow "prefix") and all the settings under them. I don't know if SourceTree places a custom flag in its "sourcetreeconfig" file, try to open it and if you find something like "gitflowenabled=1" then you should delete it...
Then start SourceTree and see if the option to enable git flow in your repo is enabled again.
Hope this helps..
I should clarify that I wanted to use gitflow within sourcetree. The only reason that I was trying to run git-flow in a terminal is because sourcetree told me that I had to run git flow init. So I assumed that it wanted me to do that.
It turns out that the respository in question must have become corrupted somehow. I cloned a new snapshot, setup gitflow, and then it started working. Sourcetree does in fact initialize the repo. Unfortunately, I have no idea how to figure out what went wrong in the other repository. I'll try your suggestion about modifying the config file and let you know what happens.
I'm concerned about your statement that I should NEVER use the GUI to issue git-flow commands. The team is primarily using the sourcetree gui for issuing most git commands. Earlier you wrote, "nvie git-flow version that SourceTree uses, as it's somewhat buggy and is not actively maintained anymore."
I am relatively new to Git and Sourcetree so I do not understand some acronyms and terms that you use. What is nvie? How do you know that something is not actively maintained anymore?
His warning is only relevant if you use the non-standard fork of git-flow from petervanderdoes.
Thank you Paolo. Your suggestion to manually delete the git flow info from the config file worked. I did that, and then started over. Then I was able to start a new feature branch successfully.
One more issue that I noticed is that although the tool allows you to type whatever you want for the master and develop branches, it does not seem to like it if you set the master and develop branches to be the same. My current project doesn't really use the master so I tried to set it up so that both are dev. Sourcetree doesn't complain when I setup gitflow. It only complains with a cryptic error after I try to start a feature. That seems like a bug to me, and that is probably the root cause of the original error that I saw. I tried it again, and I can duplicate it. It gives the error, "fatal: Not a gitflow-enabled repo yet. Please run "git flow init" first." which does tell me anything about the actual problem. When I followed paolo's advice I just entered master for master and dev for develop.
git-flow implements a set of commands (that are simply a sequence of plain git commands) around a typical workflow, and it assumes that you have at least two branches, one for mainstream code and one for developing and integrating new code (develop). I don't know if git-flow at command line permits a single branch for both roles, or if someone else's fork does.. but as it's not the intended setup, I suspect it won't never be considered a bug...
In the end, my advice is to take some time to better understand the git (and more in general, DVCS) philosophy, experiment with various git commands at the command line, and come up with a sustainable workflow for your team.
After that you'll find that you don't need git flow, and that a simple workflow can be managed with a small subset of plain git commands.
The "bug" is that the GUI does not make it clear what the problem is. If the intent is for master and dev to be different then it should tell you that and not allow you to enter something wrong, and then provide a cryptic error later on that causes users to waste time trying to figure out what is wrong.
I see.. then I agree with you, the GUi must complain when entering the same branch in git-flow init dialog. file a bug to the ST team..
Although this is an old post, just wanted to add to this since I've gotten stuck on this same error. Was able to resolve by doing the following:
Once I did this, was able use the GitFlow functionality again (start new branches, finish releases, etc). Hopefully this will work for any others who encounter this problem.
Thx! It resolves my problem. imo, TortoiseGit may interfer with .git/config file when TortoiseGit and SourceTree are both installed.
Thank you jpfl, this also resolved my issue!
This fixed the issue. I believe the problem was that I removed my "master" branch because I was never even using it and that broke git flow.
For me (and as someone mentioned above), the problem was that I had deleted the master branch from my local. Checking out the master branch again fixed my problem, and this solution was simpler than jpfl's.
This explanation from Kieran Senior [Atlassian] helped me to better understand this and other similar problems using SourceTree GitFlow at: https://answers.atlassian.com/questions/146292/git-flow-post-initialization-issue-recovery.