4 ms·

This is one thing that the FAANG workflow gets right. Multiple stacked commits are great as long as each one is a reviewable unit that makes sense on its own, a

This is one thing that the FAANG workflow gets right. Multiple stacked commits are great as long as each one is a reviewable unit that makes sense on its own, and they don't need to be squashed to merge to main. What you need to avoid are a stack of commits like "added some code today" and "fixed bugs" and "try #3". Learn to amend existing commits instead...

plugin-baby 4y ago
> What you need to avoid are a stack of commits like "added some code today" and "fixed bugs" and "try #3". That’s what you need to avoid in your mainline. Mandating what developers do in development branches is like having a dress code at work and then complaining about your colleague’s choice of underwear.
- int0x80 4y ago
  Nobody mandates developers about their private repos and commits, nobody cares about that. This is about what gets merged into master or what gets submitted for review.
- LaLaLand122 4y ago
  Nobody cares about the underwear... until people create a PR explicitly saying "look at my underwear".
  - ianlevesque 4y ago
    And GitHub makes it 1-click easy to make a pull request full of underwear so it happens all the time.
nyanpasu64 4y ago
Squashing commits loses history, rebasing messy commits pollutes the "first parent" history, merging messy commits is cleaner but can force bisectors to wade through dead ends (which may or may not be useful, and may be worth preserving in a permanent side branch not merged), and rewriting commit histories into atomic commits (what I do most of the time) is difficult work which can take as long as writing the features upfront, and if done wrong can produce non-building commits. Sadly I haven't found a good solution for the workload yet, but this article suggests `git rebase -i main --exec "make"`, which I'll be sure to try when I have a chance.

4 ms·

This is one thing that the FAANG workflow gets right. Multiple stacked commits are great as long as each one is a reviewable unit that makes sense on its own, a

by ianlevesque 4y ago

plugin-baby 4y ago
> What you need to avoid are a stack of commits like "added some code today" and "fixed bugs" and "try #3". That’s what you need to avoid in your mainline. Mandating what developers do in development branches is like having a dress code at work and then complaining about your colleague’s choice of underwear.
- int0x80 4y ago
  Nobody mandates developers about their private repos and commits, nobody cares about that. This is about what gets merged into master or what gets submitted for review.
- LaLaLand122 4y ago
  Nobody cares about the underwear... until people create a PR explicitly saying "look at my underwear".
  - ianlevesque 4y ago
    And GitHub makes it 1-click easy to make a pull request full of underwear so it happens all the time.
nyanpasu64 4y ago
Squashing commits loses history, rebasing messy commits pollutes the "first parent" history, merging messy commits is cleaner but can force bisectors to wade through dead ends (which may or may not be useful, and may be worth preserving in a permanent side branch not merged), and rewriting commit histories into atomic commits (what I do most of the time) is difficult work which can take as long as writing the features upfront, and if done wrong can produce non-building commits. Sadly I haven't found a good solution for the workload yet, but this article suggests `git rebase -i main --exec "make"`, which I'll be sure to try when I have a chance.