> Rebasing is definitely the better option if you can do it. A bold claim. > but for obvious reasons you should avoid that when at all possible. Obvious? I

> Rebasing is definitely the better option if you can do it. A bold claim. > but for obvious reasons you should avoid that when at all possible. Obvious? I do this somewhat regularly and haven't had a problem. I don't even know what the problem is supposed to be. Also, I never rebase. Maybe that's why I don't have a problem? When you rebase, commit A becomes commit A'. This becomes a problem when you need to determine whether a particular commit is an ancestor or not. A and A' have different commit hashes, so the identity of the commit becomes somewhat ambiguous. My workflow is do all development using merge only. When the code review is complete, squash to master. I have found no down sides to this. But I'm not trying to sell it to you either.