Git Branching – Why Git Commits Lack Branch Names

branchinggit

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?

Best Answer

Probably because branch names are only meaningful within one repository. If I'm on the make-coffee team and submit all my changes through a gatekeeper, my master branch might get pulled to the gatekeeper's make-coffee-gui branch, which he will merge with his make-coffee-backend branch, before rebasing to a make-coffee branch that gets merged into the central master branch.

Even within one repository, branch names can and do change as your workflow evolves. master might change later to be called development, for example.

As CodeGnome alluded, git has a strong design philosophy of not baking something into the data if it isn't needed. Users are expected to use options in git log and git diff to output the data to their liking after the fact. I recommend trying some out until you find a format that works better for you. git log --first-parent, for example, won't show the commits from a branch being merged in.

Related Topic