lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <>
Subject Re: Git Policy/Preference: how to fold in feature branches? squash?
Date Fri, 25 Mar 2016 08:31:37 GMT
> ...because, unless i'm missing something, if i don't use --squash then every
> intermediate commit to branch jira/SOLR-445 will be replayed on master

I think it's best explained in terms of patches and single commits, Chris.

1) git merge (no fast forward)

This creates a single merge commit that points to two parents -- the
previous commit on master and the latest commit on jira/SOLR-445. It
will preserve the history of commits on jira/SOLR-445 (exact hashes of
those commits you made, etc.).

2) git merge (fast forward)

If there were no intermediate commits on master since you branched
jira/SOLR-445 the merge commit is not strictly necessary -- you can
simply move the label of 'master' to the latest commit in
jira/SOLR-445. This would also preserve all the commits you made on
jira/SOLR-445, but you would no longer clearly "see" the branch-merge
deviation from the master "line". Try gitk --all if you don't know
what I mean.

3) git merge --squash

this is effectively taking a diff of all the commits that happened on
jira/SOLR-445 since it was branched from master, and this diff is
applied to master as a single commit. There is no "record" of where
the patch comes from (unless you leave the default commit log, which
includes commit hashes, but they don't mean a thing if you remove

> is a regular "git merge --no-squash" prefered for some reason i'm overlooking?

All of the above are useful, depends on the situation. A single
"squashed" commit is simpler to port across to other branches (it's a
single "patch" after all). It also helps to drop the noisy changes
that possibly happened during development (nocommits, intermediate
refactorings, etc.), leaving only the "clean" feature patch.

On the other hand, if the feature branch is long-lived and you want to
merge more than once (for some reason), you're better off with a
regular merge (because then subsequent merges would only apply
differential commits).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message