[jh3]

> I still fucking hate rebasing and get tripped up by it on the few times I end up having to deal with it.

When I had no understanding of what was going on, I didn't like it either. Now that I use it frequently, I understand it better, so I don't hate it anymore.

I like running `git rebase <main-branch>`, where <main-branch> is typically master, in my-new-thing branch because it lets me deal with any conflicts from upstream one by one.

I also like running `git rebase -i` in my-new-thing when I have a bunch of commits with redundant messages that I want squashed into a single commit before I push the changes. Basically anything that requires messing around with a range of commits is a good use case for `git rebase -i`.

Why do you hate it so much? There's really not much going on that you should have to hate. To me it's like a bunch of small, compartmentalized merges.

[hnrodey]

Genuinely curious, why the love for the `git rebase -i`? I find it much easier and more intuitive to squash a set of linear commits on a branch using `git reset --soft HEAD~n` where n is the number of commits to go back and "undo". Then make one more commit and you're off to the races. Note: this is not useful if force push is disabled and you've already pushed some of the commits to the remote (feature) branch.

[FullyFunctional]

In addition to bpicolo's point below, things quickly break down if your commits have file removal or renames. I've gotten bitten more than once and now always resort to git rebase [-i] to avoid this.

[bpicolo]

rebase -i doesn't force you to squash all the commits, and also lets you clean up commit messages

[alanh]

Congratulations on learning it, but that hardly means that it’s particularly user-friendly or intuitive.

I also like rebasing from time to time, but I do feel like I’m tiptoeing on a tightrope above the alligator pit when I do so.