FAQ

Can I use Git Flow Chart when we don't (strictly) follow git flow?

Yes, no problem. If you don't always use feature branches or if you branch your feature branches off from master and don't use a develop branch, Git Flow Chart will still give you better insight in the state of your repo than most charts. If you commit everything on master and your flow is basically linear, there is not much value to the chart.

Does Git Flow Chart support non-standard naming conventions?

Yes, by default, the chart uses 'develop' for the develop branch and 'feature/', 'release/' and 'hotfix/' prefixes. If you use other names, you can change these defaults in the repository settings screen.

Why is the chart not 100% correct?

Git does not keep track of the history of branches. Branches are a moving label pointing to the HEAD (current) revision of the branch, but git keeps no historic information of which commits have been the HEAD of a branch in the past. So if you want to draw the develop branch as a line, you are essentially guessing. The last commit is certain, but whenever a commit has multiple parents, we have to make an educated guess on which parent was on develop and which commit was a merged in feature or release branch. If you keep strictly to git flow, there must be one 'true' develop line, but it can be hard to decide which it is. Git Flow Chart uses many hints in these decisions, including the commit messages on merges. It helps to keep the unchanged commit messages as git would suggest them.

My master branch is not correct

In git flow, the master branch is normally easier to isolate than the develop branch, because all of the release tags must be on it. The algorythm assigns large weight to tags that look like a release tag. By default, it uses the form x.x[.x[.x]] where x can be one or more digits. If your release tags look different, you can enter an appropriate regular expression in the repository settings screen.

I see multiple develop branches. How come?

This may seem strange, but is actually normal. If multiple developers work on the repo at the same time, they don't always have their local develop branches synchronized. When they commit on develop and later pull/push, they will have multiple develop lines, joining again at the implicit merge that happened when they pulled. Git Flow Chart tries to recognize these situations and will draw multiple develop lines. When it fails to recognize this situation, part of the develop branch might appear like a feature branch.

The chart draws commits on develop that were on a feature branch when I made them

In general, see the previous FAQ ('Why is the chart not 100% correct?'). Specifically, when a feature branch is merged back to develop using fast-forward merging, the commit is actually on two branches: on the feature branch AND on develop. Git Flow Chart picks develop over the feature branch in these cases. So a feature branch with only one commit that is immediately merged back using fast-forward will appear as a direct commit on develop.

The javascript code is on GitHub, is Git Flow Chart Open Source?

No, it is not. If you are using the code in a commercial instance of Atlassian Stash, you will need to purchase a license. Atlassian does have great offers for Open Source projects or Academic users. However, we do want to share the code and allow you to inspect, study and contribute improvements. For that reason, the core code of Git Flow Chart is hosted on GitHub. It is a javascript library and comes with unit tests and a standalong HTML page that allows you to test improvements locally. Feel free to fork!