5 ms·

.... Why not rebase before merging into main?

entangledqubit 3y ago
I'm a big fan of that practice but I get the impression that rebasing scares a lot of devs that either didn't take the time to learn git or are still recovering from that one time that their change got too far away from mainline. That latter reason is why I prefer the practice actually...
- nerdponx 3y ago
  Or they were taught Git the wrong way, by memorizing a bunch of commands, as in TFA.
- hughesjj 3y ago
  When in doubt, git diff main>~/patch.out (... && Git checkout main && git pull --rebase && git checkout -B clean_branch && git apply ~/patch.out) (I like the light rhyming of the first part)
jkubicek 3y ago
Resolving rebase conflicts is technically and conceptually much more difficult than resolving merge conflicts, with the added bonus that rebasing can sometimes force you to resolve conflicts for each commit in your branch. Here's how I think everyone should use git: 1. Create a new branch for your changes 2. Make commits and merge from main with wild abandon 3. One final merge from main 4. Squash everything into a single commit, push a PR If you keep your branch focused on only a single change, the end result is a tight, focused, single commit PR that merges cleanly into main and didn't involve any complex or error-prone shenanigans.
- skeeter2020 3y ago
  This is a very common workflow for larger OS projects, and I think it translates really well to corporate environments too. It reinforces some work/feature discipline and gives you a nice clean history.
- crispyambulance 3y ago
  This is how I do it. Almost never touch rebase. Also, I hate git :-)
  - jkubicek 3y ago
    I love git, but I also never touch rebase. It's there when I need it, but I also work in such a way to never need it.
- hughesjj 3y ago
  So, I get the "squash your feature branch into a single commit before merging upstream", but what does doing "git merge main" instead of "git rebase -i main" give you? (Assume I have my global git config to remember conflict resolutions via rerere)
- seba_dos1 3y ago
  > Resolving rebase conflicts is technically and conceptually much more difficult than resolving merge conflicts The opposite is true: resolving a conflict during a rebase is much easier, as you get to resolve the conflict in the context of a single commit and its parent. In some cases it may end up being more work than resolving a whole merge, but it's much easier to reason about.

I'm a big fan of that practice but I get the impression that rebasing scares a lot of devs that either didn't take the time to learn git or are still recovering from that one time that their change got too far away from mainline. That latter reason is why I prefer the practice actually...

nerdponx 3y ago
Or they were taught Git the wrong way, by memorizing a bunch of commands, as in TFA.
hughesjj 3y ago
When in doubt, git diff main>~/patch.out (... && Git checkout main && git pull --rebase && git checkout -B clean_branch && git apply ~/patch.out) (I like the light rhyming of the first part)

jkubicek 3y ago

Resolving rebase conflicts is technically and conceptually much more difficult than resolving merge conflicts, with the added bonus that rebasing can sometimes force you to resolve conflicts for each commit in your branch. Here's how I think everyone should use git: 1. Create a new branch for your changes 2. Make commits and merge from main with wild abandon 3. One final merge from main 4. Squash everything into a single commit, push a PR If you keep your branch focused on only a single change, the end result is a tight, focused, single commit PR that merges cleanly into main and didn't involve any complex or error-prone shenanigans.

skeeter2020 3y ago
This is a very common workflow for larger OS projects, and I think it translates really well to corporate environments too. It reinforces some work/feature discipline and gives you a nice clean history.
crispyambulance 3y ago
This is how I do it. Almost never touch rebase. Also, I hate git :-)
- jkubicek 3y ago
  I love git, but I also never touch rebase. It's there when I need it, but I also work in such a way to never need it.
hughesjj 3y ago
So, I get the "squash your feature branch into a single commit before merging upstream", but what does doing "git merge main" instead of "git rebase -i main" give you? (Assume I have my global git config to remember conflict resolutions via rerere)
seba_dos1 3y ago
> Resolving rebase conflicts is technically and conceptually much more difficult than resolving merge conflicts The opposite is true: resolving a conflict during a rebase is much easier, as you get to resolve the conflict in the context of a single commit and its parent. In some cases it may end up being more work than resolving a whole merge, but it's much easier to reason about.