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, mymaster
branch might get pulled to the gatekeeper'smake-coffee-gui
branch, which he will merge with hismake-coffee-backend
branch, before rebasing to amake-coffee
branch that gets merged into the centralmaster
branch.Even within one repository, branch names can and do change as your workflow evolves.
master
might change later to be calleddevelopment
, 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
andgit 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.