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

In response to accelerated release cycles, a new set of testing capabilities is now required to deliver quality at speed. This is why there is a shake-up in the testing tools landscape—and a new leader has emerged in the just released Gartner Magic Quadrant for Software Test Automation.

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.

Recently published Gartner Magic Quadrant Report for Software Test Automation provides an objective benchmark of all test automation solutions based on industry surveys, customer inquiries, product evaluations, and more. 

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 }}