4 ms·

In most sane development cycles I've seen (from 2-people teams to 100k people teams), intermediate commits disappear as soon as you merge your branch (in other

by herval 1y ago

In most sane development cycles I've seen (from 2-people teams to 100k people teams), intermediate commits disappear as soon as you merge your branch (in other words, you do short lived branches + squash merge). If you decide to do merges without squashing, then yes, you gotta have to have more hygiene on each individual commit. It creates a lot of unnecessary friction and it's guaranteed to be slower (devs can't use commits as checkpoints/savepoints on their work, but rather each commit becomes a fully fleshed out "intermediate final state"). The only situation where I see this making sense is if you share work on a branch with other engineers (which is also a bad idea).

m000 1y ago
> devs can't use commits as checkpoints/savepoints on their work But they can! In git you can do whatever you want with your local/remote working branch. And after you're done it's pretty straightforward to massage it into a coherent series of commits (especially if you had been working with that in mind). > each commit becomes a fully fleshed out "intermediate final state" This is really a team decision. You can allow intermediate commits to e.g. fail the tests, and add a tag to your main/master after each merge. Then you know that only the tagged commits are guaranteed to be fully functional.
- herval 1y ago
  > And after you're done it's pretty straightforward to massage it into a coherent series of commits Why waste time? Just squash and merge, you have a single commit and it WORKS. Intermediate messages disappear and you have a single, atomic rollback point on your main branch > You can allow intermediate commits to e.g. fail the tests, and add a tag to your main/master after each merge. Then you know that only the tagged commits are guaranteed to be fully functional. OR… squash and merge. Block merging with tests and compilation passing For anything in tech, there’s the frictionless way and the busywork way. Both of your examples are busywork that’s completely unnecessary if you just… squash and merge The best process is the process nobody needs to remember to do shit for it to work
  - m000 1y ago
    Everything works, until it doesn't. You always have the PR discussion to refer to, until you move to a different platform to cut costs. You can always ask the author of the code, until they have left the company.
    - herval 1y ago
      The squashed commit message remains, even in your extremely unlikely examples. Not sure what you’re protecting yourself against, in reality

by herval 1y ago

m000 1y ago

> devs can't use commits as checkpoints/savepoints on their work But they can! In git you can do whatever you want with your local/remote working branch. And after you're done it's pretty straightforward to massage it into a coherent series of commits (especially if you had been working with that in mind). > each commit becomes a fully fleshed out "intermediate final state" This is really a team decision. You can allow intermediate commits to e.g. fail the tests, and add a tag to your main/master after each merge. Then you know that only the tagged commits are guaranteed to be fully functional.

herval 1y ago
> And after you're done it's pretty straightforward to massage it into a coherent series of commits Why waste time? Just squash and merge, you have a single commit and it WORKS. Intermediate messages disappear and you have a single, atomic rollback point on your main branch > You can allow intermediate commits to e.g. fail the tests, and add a tag to your main/master after each merge. Then you know that only the tagged commits are guaranteed to be fully functional. OR… squash and merge. Block merging with tests and compilation passing For anything in tech, there’s the frictionless way and the busywork way. Both of your examples are busywork that’s completely unnecessary if you just… squash and merge The best process is the process nobody needs to remember to do shit for it to work
- m000 1y ago
  Everything works, until it doesn't. You always have the PR discussion to refer to, until you move to a different platform to cut costs. You can always ask the author of the code, until they have left the company.
  - herval 1y ago
    The squashed commit message remains, even in your extremely unlikely examples. Not sure what you’re protecting yourself against, in reality