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
Then, after the bugfix, merge this branch into the release branches, avoiding a fast-forward merge
git merge --no-ff.
That is now a screenshot, how gitk is displaying PMD’s commit 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:
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.