This post is about, how your git history might look like, if you consequently fix bugs on branches and merge this bugfix-branches into the release branches. In this case, I used the method described earlier in “Roadmap and source code branches” in New PMD Release 5.4.0: Always create a new branch, that can be merged in the release branches, determined by git merge-base. Then, after the bugfix, merge this branch into the release branches, avoiding a fast-forward merge by using git merge --no-ff.

That is now a screenshot, how gitk is displaying PMD’s commit history:

gitk screenshot of PMD's history

There are lots of parallel lines. It might be a bit confusing, but as long as you have good tools such as git, that’s ok :)

For example, you want see only the “real” commits, then you would execute gitk --no-merges. This shows you all but the merge-commits, which makes it more clearer.

Also, some interesting commands are comparing branches. E.g. gitk pmd/5.3.x..master would show all commits, that are on branch “master” bot not on branch “pmd/5.3.x”. So, before cutting a release from master, you would verify the other way round: all bugfixes on the branch should also be on the master: gitk master..pmd/5.3.x. If you run it like this, you will see a couple of commits - these are the merge-commits which exist on each individual branch. If you add additionally the “–no-merges” flag like gitk master..pmd/5.3.x --no-merges you’ll end up with no commits, which means, all bugsfixes have already been merged into the master branch, too. By the way - this also works on the commandline without a gui using git log. gitk is using the same command line parameters as git log, so git log master..pmd/5.3.x --no-merges should yield no commits.