When working with git in a team using feature branches, I often find it difficult to understand the branch structure in history.
Example:
Let's say there was a feature branch feature/make-coffee, and bugfixing continued on master in parallel to the feature branch.
History might look like this:
* merge feature/make-coffee
|\
| * small bugfix
| |
* | fix bug #1234
| |
| * add milk and sugar
| |
* | improve comments
| |
* | fix bug #9434
| |
| * make coffe (without milk or sugar)
| |
* | improve comments
|/
*
Problem
At first glance, I find it difficult to tell which side is the feature branch. I usually need to browse several comments on both sides to get an idea of which is which. This gets more complicated if there are multiple feature branches in parallel (particularly if they are for closely related features), or if there was merging in both directions between feature branch and master.
As a contrast, in Subversion, this is significantly easier because the branch name is part of the history - so I can tell right away that a commit was originally made on "feature/make-coffee".
Git could make this easier by including the name of the current branch in the commit metadata when creating a commit (along with author, date etc.). However, git does not do this.
Is there some fundamental reason why this is not done? Or is it just that nobody wanted the feature? If it's the latter, are there other ways of understanding the purpose of historical branches without seeing the name?