3 ms·

Yeah, I'd say "if you use merge you're doing it wrong". Rebase + squash everything is the only way to go unless you're merging a giant feature branch in... and

by ajkjk 3y ago

Yeah, I'd say "if you use merge you're doing it wrong". Rebase + squash everything is the only way to go unless you're merging a giant feature branch in... and even then, try to avoid that.

GolDDranks 3y ago
I'd say that git rebase -i + squashing selectively is my favorite. I generally strive to make each commit into a meaningful set of changes than I can explain one-by-one, but if they are too big, it's harder to review.
CuriousCosmic 3y ago
I'd staunchly disagree. Merges make sense when you develop with the patchset git style. i.e. 1. Write a bunch of code and just scratch it out, stashing in your `FEATURE` branch until the feature is done. 2. Rebase that `FEATURE` branch into sane commits that each accomplish an atomic substep in the implementation of your feature. Each discrete commit/change should build and pass tests. 3. Open your code for review, either via a PR or by submitting the patchset to a mailing list. 4. Implement requested changes as a `FEATURE-v2` (or `FEATURE-vX`) branch. 5. Rebase your `FEATURE-v2`/`FEATURE-vX` branch to clean up your changes and get them to roughly line up with your "final" commits from your previous `FEATURE` branch. 6. Submit your new patchset revision to the mailing list in reply to your last patchset revision. Or if you are using pull requests, change the merging branch from `FEATURE` to `FEATURE-v2`. Then cycle back to step 4-6, rinse repeat until everyone is happy. Then you merge in the final `FEATURE-vX` branch. This leaves you with a history where each individual commit is a useful, descriptive, and fully functional change to the codebase but also with a merge for the full feature at the top. That's important because git tooling actually can iterate over all commits or over only top level commits without traversing into merges. Then it's way easier to identify which feature introduced the issue in question and you can easily peek into the feature's individual commits to understand each discrete change and exactly what the intent was.
- ajkjk 3y ago
  Definitely disagree. No individual commits should ever exist that aren't safe in prod. Your intermediate commits could be any old state, plus they're not useful in the future. The unit of code landing should be the single commit unless the team as a whole does parallel development in a separate branch for a while.
lmm 3y ago
Rebase and squash makes your bisects worse for no real benefit. OP is wrong about commit messages ("fixp" is fine, most of the time you're not going to read the commit message) but right about everything else on the git side.
- juped 3y ago
  of course no one reads your commit messages if they're useless!
  - lmm 3y ago
    I've worked at places that enforced "good" commit messages. They didn't get read any more, they just meant people committed less often and so commits were less atomic (e.g. people wouldn't bother splitting formatting changes out into a separate commit because they'd have to write another commit message) and bisect was less useful.
    - ajkjk 3y ago
      Good commit messages are about 1s more work than bad ones. They don't have to be long, they just have to say something concrete and useful and instill confidence in the change. If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction.
      - lmm 3y ago
        > If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). Sure. But the point is to get away from doing those "complicated arduous change"s, and split them up into much smaller pieces. Being able to commit without breaking your flow helps a lot with that. > But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction. This is a purely circular argument. "It's important to have high quality commit messages so that you will have high quality commit messages". It really isn't.

by ajkjk 3y ago

Yeah, I'd say "if you use merge you're doing it wrong". Rebase + squash everything is the only way to go unless you're merging a giant feature branch in... and even then, try to avoid that.

GolDDranks 3y ago

I'd say that git rebase -i + squashing selectively is my favorite. I generally strive to make each commit into a meaningful set of changes than I can explain one-by-one, but if they are too big, it's harder to review.

CuriousCosmic 3y ago

I'd staunchly disagree. Merges make sense when you develop with the patchset git style. i.e. 1. Write a bunch of code and just scratch it out, stashing in your `FEATURE` branch until the feature is done. 2. Rebase that `FEATURE` branch into sane commits that each accomplish an atomic substep in the implementation of your feature. Each discrete commit/change should build and pass tests. 3. Open your code for review, either via a PR or by submitting the patchset to a mailing list. 4. Implement requested changes as a `FEATURE-v2` (or `FEATURE-vX`) branch. 5. Rebase your `FEATURE-v2`/`FEATURE-vX` branch to clean up your changes and get them to roughly line up with your "final" commits from your previous `FEATURE` branch. 6. Submit your new patchset revision to the mailing list in reply to your last patchset revision. Or if you are using pull requests, change the merging branch from `FEATURE` to `FEATURE-v2`. Then cycle back to step 4-6, rinse repeat until everyone is happy. Then you merge in the final `FEATURE-vX` branch. This leaves you with a history where each individual commit is a useful, descriptive, and fully functional change to the codebase but also with a merge for the full feature at the top. That's important because git tooling actually can iterate over all commits or over only top level commits without traversing into merges. Then it's way easier to identify which feature introduced the issue in question and you can easily peek into the feature's individual commits to understand each discrete change and exactly what the intent was.

ajkjk 3y ago
Definitely disagree. No individual commits should ever exist that aren't safe in prod. Your intermediate commits could be any old state, plus they're not useful in the future. The unit of code landing should be the single commit unless the team as a whole does parallel development in a separate branch for a while.

lmm 3y ago

Rebase and squash makes your bisects worse for no real benefit. OP is wrong about commit messages ("fixp" is fine, most of the time you're not going to read the commit message) but right about everything else on the git side.

juped 3y ago
of course no one reads your commit messages if they're useless!
- lmm 3y ago
  I've worked at places that enforced "good" commit messages. They didn't get read any more, they just meant people committed less often and so commits were less atomic (e.g. people wouldn't bother splitting formatting changes out into a separate commit because they'd have to write another commit message) and bisect was less useful.
  - ajkjk 3y ago
    Good commit messages are about 1s more work than bad ones. They don't have to be long, they just have to say something concrete and useful and instill confidence in the change. If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction.
    - lmm 3y ago
      > If anything, after doing a complicated arduous change writing a nice simple message to summarize it is really cathartic and destressing (for me at least). Sure. But the point is to get away from doing those "complicated arduous change"s, and split them up into much smaller pieces. Being able to commit without breaking your flow helps a lot with that. > But realistically the point of good commit messages is similar to the point of code formatting standards, which is to prevent the https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory on your codebase. If everything you do is held to a high standard, you'll hold everything you do to a high standard. If the organization stops doing that quality stays the same for a while but eventually slips and slips and slips. It is important to always enforce slightly more quality than you have now to keep the momentum in the other direction. This is a purely circular argument. "It's important to have high quality commit messages so that you will have high quality commit messages". It really isn't.