3 ms·

It's not fun if you rebase, and realize that every single one of your many commits need to hand-merged.

• derenge 6y ago
  Agreed, I used to interactively rebase but have since switched to a four step process. If you have conflicts, you'll deal with them all at once when you merge in `origin/master`. git fetch git merge origin/master git reset origin/master git commit
• Vinnl 6y ago
  But you need to deal with those conflicts before merging anyway? And they're a lot easier to deal with in the context of the individual commits than when dealing with one big merge commit, I find.
  • kelnos 6y ago
    The issue is that when you rebase, each commit in the chain gets re-applied, one by one. If you change something in an earlier commit that affects later commits, you could end up having to fix the same or similar conflicts several times before the rebase finishes (even with git's conflict resolution cache). In contrast, if you instead merge, you only have to resolve conflicts once, for the merge commit. That being said, I tend to be very fastidious about cleaning up my history before pushing, even if it means tedious, repetitive conflict resolution. But I do understand that other people might not think it's worth the trouble.
    • Vinnl 6y ago
      I think that can be resolved by rebasing onto the first commit of your branch to first make sure all the commits are minimal, and only then to rebase onto your main branch. That said, I must say that I've personally experienced as a pain, so I don't actually do that.