Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Git: To Squash or Not to Squash?

DZone's Guide to

Git: To Squash or Not to Squash?

Take a quick look at the benefits and downsides to squashing all the commits on a given feature branch to just one commit.

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

Until recently, I told my team to squash all of their commits on a given feature branch to just one commit. Every feature branch consisted of just this one commit and could be integrated into develop so that develop reads just like a sequence of features. After further consideration, I changed that. Here are reasons for both approaches:

Pro-Squash

  1. Clean timeline: Development of features is clearly visible because every commit is a feature.
  2. Commits representing work in progress (WIP) broke builds on CI-server.
  3. WIP-commits prevented "jumping a month into the past" for debugging and exploratory purposes because they are potentially broken (compile errors, failing tests).

Anti-Squash

  1. If feature branches are merged, a merge commit is created that represents the development of a feature.
  2. Tools like Git Bisect are much more powerful when dealing with small commits.
  3. In IDEs like IntelliJ IDEA, feature branches in the Git history can be collapsed to provide a better overview.
  4. Small tasks are better visible. For example, small bugfixes tended to be fixed in bigger feature branches, just to be never found again. "Yeah, this got fixed somewhere, but I don't know where"-syndrome.
  5. Every commit causes the CI-server to build. The more (pushed) commits, the more builds, the faster feedback if something went wrong.

To get the most out of the new strategy, each commit must

  1. Compile and run green (all tests), AND
  2. Have a good commit-message (see 7 rules of good commit messages).

Furthermore, really small commits may be merged with a fast-forward-merge/rebased onto develop.

Also, commits that represent a quick-WIP-save have to be edited in retrospect and provided with a good commit message. This is the last remaining situation in which a squash is allowed.

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:
git ,devops ,feature branching ,commits

Published at DZone with permission of Steven Schwenke. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}