Git merge - to squash or not to squash?

Question

I'm currently working on implementing guidelines for git usage in a fairly complex development environment, and while I think I have the basics set up pretty well, there is one question in particular I would like some input on if that's at all possible. This isn't so much a purely technical question, as in that it's more about which of the available options is most appropriate.

Basically, I'm leaning towards a system that closely mirrors the common "git flow" structure ( http://nvie.com/posts/a-successful-git-branching-model/ ), with some exceptions to adapt it to our development environment. In short:

• A project will have at least a 'develop' and 'master' branch
• 'master' will contain the latest production ready code
• 'develop' will contain the latest merged code
• Anything else will be in either a 'feature/ticket{number}' or 'hotfix/ticket{number}' branch
• Feature branches will be made from 'develop', hotfix branches from 'master'
• The number in the branch name will always correspond with the ticket number in our own change/bug system
• Features can be tested individually, but also in combination, by building the appropriate branch or merging it to 'develop' first

So far, it's really helped us streamline our development and prevent conflicts between projects. The one detail that's spawned some debate here is; should we merge feature/ticket branches back into their respective origins with the '--squash' option? I'm somewhat of a fan of this, and what I like about it:

• The git log for develop remains clean and readable, all commits will simply state the original branch name (which tells us if it was a hotfix or a feature, and the ticket number)
• Even after clearing out the original feature or hotfix branch, the merge can cause no confusion afterwards

Maybe these reasons won't turn out to be good enough, and maybe there's good reasons not to use '--squash' in this scenario. Any thoughts?

Answer 1

[S]hould we merge feature/ticket branches back into their respective origins with the --squash option?

It all depends how fine-grained you want the history of your repo to be. Keep in mind that version control, via commit messages, is a form of code documentation. Squashing willy-nilly is certainly not good practice. It may be fine for a hotfix branch, but rarely is for a substantial feature branch.

As an analogy, imagine if you asked me for a lend of my Lost DVD boxset (ie you cloned my repo), and I just gave you the box, no DVDs, and told you

Here, just read the summary of the series on the backcover. That should tell you enough about the plot.

So, by all means, squash your commits when you want to get rid of intermediate steps that are needlessly detailed or not self-contained enough, but not to the point that it obscures the evolution of your repository.

---

(I discuss this matter further in this Twitter thread .)

Answer 2

Don't squash: the small commits are useful especially for later tracking down of bugs with git bisect , and anyway you don't want to change the history much. Just use a merge commit ( git merge --no-ff ) to keep the history organized.