Re: Preserving branches after merging on ancestor

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Richard,

Richard Lee wrote:
 
> One way of getting round this problem is to use empty commits on the master
> branch, as shown below.
> 
> *   6fc04b5 Merge branch 'feature2'
> |\
> | * 07a117b stuff on feature2
> * | 52f5ba1 Empty commit
> |/
> *   5deaa93 Merge branch 'feature1'
> |\
> | * b163b17 stuff on feature1
> | * 53bb820 stuff on feature1
> | * c9ef14c stuff on feature1
> * | 34227a3 Empty commit
> |/
> * e88d332 Init
> 
> But is this correct? It seems rather hackish to create empty commits on the
> master branch just to historically preserve commits on a seperate branch.
> Should I be using feature branches in git like this or another way? For
> example more informative commit messages. 

As Eric said, you can avoid the empty commits by passing 'git merge'
the --no-ff option, which would give the history I think you intend:

*   26749ab Merge branch 'feature2'
|\
| * b9cd8ff stuff on feature2
|/
*   829ba2c Merge branch 'feature1'
|\
| * b163b17 stuff on feature1
| * 53bb820 stuff on feature1
| * c9ef14c stuff on feature1
|/
* e88d332 Init

But doing this misses some of the main benefits of feature branches
imho.

If you base each feature branch on the stable release or features it
depends on instead, this gives you the freedom to merge one feature without
the others to another branch.  For example:

# wouldn’t feature1 be neat? let me try it.
git checkout -b feature1 v1.0
hack hack hack
# looks good.
git commit -a

# how about an unrelated feature2?
git checkout -b feature2 v1.0
hack hack hack
# looks good.
git commit -a

# but do they work?
git checkout v1.0; # detach head for testing [1]
git merge feature1 feature2
make check
# hmm, these don’t seem to work well together
... (investigating some more)

# looks like feature1 is not ready for prime time
# so let’s just use feature2 for now.
git checkout master
git merge feature2
git branch -d feature2
make check
# looks good; better publish it.
git push origin master

v1.0 --- feature1
    \
     \-- feature2 [master]

As a nice side-effect, if you work this way then you can develop
feature2 without being distracted by new bugs introduced by feature1.

With many features built this way, the revision graph starts to give
some hints about relationships between features developed around the
same time.  For example, with the history

v1.0 --- feature1 --- feature2 -- feature4 -- feature6 - v1.1
                               \                        /
                                -- feature5 ------------

feature4 and feature5 are not likely to be closely related, but
feature4 and feature6 might be.  The exact history of merges is less
important than the general "shape" of the graph.

Thanks for the food for thought.

Hope that helps,
Jonathan

[1] See <http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html#_detached_head>.