[jkubicek]

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.

[seba_dos1]

> 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.

[skeeter2020]

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.

[hughesjj]

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)

[crispyambulance]

This is how I do it. Almost never touch rebase. Also, I hate git :-)

[jkubicek]

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.