Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Squash and Rebase in Git

jenweber.dev

Post reply on HN
Print view View original

41–50 of 59 posts

Re: How to Squash and Rebase in Git

#41

Post by julenx »

mportela wrote: post #22
unicornmama wrote: post #12

10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.

AFAIK it's usually to keep the git history clean but doing it manually is so painful. In my company, we enabled GitHub's "Squash and Merge" option (1) so we have the best of both worlds: a clean history and an 1-click squash process. (1) https://github.blog/2016-04-01-squash-your-commits/

With GitHub's squash + merge, clean history still depends on the person doing the merge, because when clicking the squash + merge button, GitHub places all commit messages in one large chunk of text, which devs are able to edit before confirming the merge, but it takes some discipline to do so.

In my experience, devs rarely pay attention to this, so commit messages end up as a big list of:

  * Ticket-1234 feature
  * fix
  * cleanups
  * fix
  * another fix
  * now the real fix
Which I wouldn't qualify as a contributor to a "clean" history. It'd be great if GitHub's UX around crafting the commit messages would be more considerate and foster more meaningful commit messages.

(edit: formatting)

Re: How to Squash and Rebase in Git

#42

Post by omegalulw »

alkonaut wrote: post #38

If I get a PR to review I want the set of commits to be clean and represent logical changes. No “oops” commits. What’s more, I also want only commits that relate to the feature implemented on the branch. Preferably no merges from the parent branch. To get zero oops commits requires squashing in the branch . Note that this is independent of whether the branch is merged or squashed when the PR is completed. Squashing 1…

> If I get a PR to review I want the set of commits to be clean and represent logical changes. No “oops” commits.

+100. Though every time this comes up on HN you would be surprised by how much some people just vehemently disagree.

I will also add another requirement - all unit tests should pass at each commit in the PR. That way, you can use the rebase strategy to merge and you would still be able to bisect.

Re: How to Squash and Rebase in Git

#43

Post by ravenstine »

alkonaut wrote: post #38

If I get a PR to review I want the set of commits to be clean and represent logical changes. No “oops” commits. What’s more, I also want only commits that relate to the feature implemented on the branch. Preferably no merges from the parent branch. To get zero oops commits requires squashing in the branch . Note that this is independent of whether the branch is merged or squashed when the PR is completed. Squashing 1…

Having logical commits are a nice-to-have IMO, but I wouldn't be so strict. An oops commit here or there doesn't necessarily throw off one's understanding of the history of what a particular group of commits is intended to do, and there isn't necessarily anything wrong with an oops commit; it's correcting an issue in a previous commit. Besides, it's more common to look at a PR as a whole rather than as individual commits. I know that sometimes you do, but at that point "oops" commits are rather trivial to look at.

What's more important is that the commit history of the main branch remain sane. That's why you might want to squash-merge, since it mostly solves the issue of having too many extraneously-named commits in a place where one indeed may want to examine individual commits.

Honestly, I couldn't give less of a crap what sort of commits someone has on their branch as long as it's not so many that I can't possibly review all of the code.

Don't get me wrong, because I think it's great if you want to maintain that sort of standard in your own work. I don't find it particularly reasonable to expect this of anyone else because it's more of an aesthetic choice than a practical one, not that either are exclusive of the other in this case.

> Preferably no merges from the parent branch.

Yes. Always rebase. Rebase frequently.

Re: How to Squash and Rebase in Git

#44

Post by alkonaut »

ravenstine wrote: post #43
alkonaut wrote: post #38

If I get a PR to review I want the set of commits to be clean and represent logical changes. No “oops” commits. What’s more, I also want only commits that relate to the feature implemented on the branch. Preferably no merges from the parent branch. To get zero oops commits requires squashing in the branch . Note that this is independent of whether the branch is merged or squashed when the PR is completed. Squashing 1…

Having logical commits are a nice-to-have IMO, but I wouldn't be so strict. An oops commit here or there doesn't necessarily throw off one's understanding of the history of what a particular group of commits is intended to do, and there isn't necessarily anything wrong with an oops commit; it's correcting an issue in a previous commit. Besides, it's more common to look at a PR as a whole rather than as individual com…

Oopses are so trivial to fix though, it’s literally a second’s work for the author to do and costs more seconds in penalty to the reviewer. So I think it’s just a reasonable etiquette to show that you value your colleagues’ time.

Re: How to Squash and Rebase in Git

#46

Post by alkonaut »

omegalulw wrote: post #42
alkonaut wrote: post #38

If I get a PR to review I want the set of commits to be clean and represent logical changes. No “oops” commits. What’s more, I also want only commits that relate to the feature implemented on the branch. Preferably no merges from the parent branch. To get zero oops commits requires squashing in the branch . Note that this is independent of whether the branch is merged or squashed when the PR is completed. Squashing 1…

> If I get a PR to review I want the set of commits to be clean and represent logical changes. No “oops” commits. +100. Though every time this comes up on HN you would be surprised by how much some people just vehemently disagree. I will also add another requirement - all unit tests should pass at each commit in the PR. That way, you can use the rebase strategy to merge and you would still be able to bisect.

Passing unit tests on each commit is only a realistic goal if developers can run all tests locally in less than (say) an hour. If the test suite is ten hours and you have ten commits on a branch then it quickly becomes silly to bog down your build servers (or cloud bills) with building and testing the intermediate commits over 90h. Using your own machine to do it (blocking it from doing other work) is obviously not a good idea either.

Re: How to Squash and Rebase in Git

#47

Post by ravenstine »

alkonaut wrote: post #44
ravenstine wrote: post #43

Earlier quoted context omitted.

Having logical commits are a nice-to-have IMO, but I wouldn't be so strict. An oops commit here or there doesn't necessarily throw off one's understanding of the history of what a particular group of commits is intended to do, and there isn't necessarily anything wrong with an oops commit; it's correcting an issue in a previous commit. Besides, it's more common to look at a PR as a whole rather than as individual com…

Oopses are so trivial to fix though, it’s literally a second’s work for the author to do and costs more seconds in penalty to the reviewer. So I think it’s just a reasonable etiquette to show that you value your colleagues’ time.

Yeah, that's totally fair, and I think I generally agree. Perhaps I just see it as less of a must. I interpreted your point of view as being relatively strict. If there was some sort there was some sort of standard for always squashing oops commits on a software team I was a part of, I'd probably have an issue with it.

Re: How to Squash and Rebase in Git

#48

Post by altonen »

mhitza wrote: post #21
unicornmama wrote: post #12

10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.

I've seen two main arguments to that workflow. One argument, and which I hear often, is that they want to keep the git history clean. The other argument is that keeping things rebased & squashed allows you to do reverts easily. I personally don't mind the merge commits cluttering the history, and especially when working on a longer lived branch I will always prefer merging-in changes rather than constantly rebasing a…

If you use git-rerere you don't have to fix the same conflicts over and over again

Re: How to Squash and Rebase in Git

#49

Post by avgcorrection »

mportela wrote: post #22
unicornmama wrote: post #12

10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.

AFAIK it's usually to keep the git history clean but doing it manually is so painful. In my company, we enabled GitHub's "Squash and Merge" option (1) so we have the best of both worlds: a clean history and an 1-click squash process. (1) https://github.blog/2016-04-01-squash-your-commits/

There’s nothing particularily clean about a multi-week pull request with 50+ commits getting squashed with all the commit messages concatenated together as bullet points. I’ve tried to go back to commits/issues like that and it’s hard to understand what one section of the commit message corresponds to in the diff.

There’s no way to automate version control.

Re: How to Squash and Rebase in Git

#50

Post by avgcorrection »

julenx wrote: post #41
mportela wrote: post #22

Earlier quoted context omitted.

AFAIK it's usually to keep the git history clean but doing it manually is so painful. In my company, we enabled GitHub's "Squash and Merge" option (1) so we have the best of both worlds: a clean history and an 1-click squash process. (1) https://github.blog/2016-04-01-squash-your-commits/

With GitHub's squash + merge, clean history still depends on the person doing the merge, because when clicking the squash + merge button, GitHub places all commit messages in one large chunk of text, which devs are able to edit before confirming the merge, but it takes some discipline to do so. In my experience, devs rarely pay attention to this, so commit messages end up as a big list of: * Ticket-1234 feature * fix…

This is exactly what happens in practice.
Post reply on HN