2

It's considered a good practice to commit to git a lot. Sometimes this is necessary where git is used as a delivery mechanism to test in the cloud.

But my git history gets cluttered up with lots of commits, each with a very small and almost meaningless commit comment.

What is the best practice? To reuse the same comment?

Or to squash commits? That seems like a hassle for ordinary day-to-day workflow. Do people do it?

Joshua Fox
  • 1,080

2 Answers2

4

While I don't think there is a problem with making lots of small meaningful git commits, I agree you don't want lots of "testing" commits (this could make any conflicts during a rebase really painful to deal with as it replays them).

I'd look into whatever tool you're using to deploy to the cloud, and there should be a way to simply test/deploy/redeploy manually (e.g., instead of letting a githook trigger the even, trigger it by clicking rebuild/rerun). I know Jenkins, Travis-CI, and Circle-CI, all have this functionality, and I'd expect most other build/deployment services allow this.

In the case each commit is to test a deployment/build configuration, such as .travis.yml, so that you might have 10 commits but only the last one makes the change you want. The teams I've worked on have used git merge --squash as @gnat suggests in these cases (or git reset --hard with copying out and back in the desired file but this is less "clean").

dlasalle
  • 842
  • +1. Another possible source of small commits is tweaking or testing in production. That should not happen! Instead, you'd want a (manually deployed) staging system where you can experiment with stuff. And whenever a bug makes it to production it shouldn't just be fixed, but also prevented from occurring again with a new test case. While these are good ideas regardless of deployment mechanism, continuous deployment really heightens the need for solid software engineering practices. – amon Sep 04 '17 at 16:03
2

Another possible scenario of using git squash might be when developing really big feature in feature branch.

Usually, what I prefer is, when working in a branch ocassionally to squash my commits in order to keep the history tight. (Its something like tags in your branches).

When it comes to merging my feature branch to master I have two options - either squash all the milestones into one in order to make possible revert easier(notice this will not be reverting merge), or leave it with milestones and merge it as it is.

kuskmen
  • 194