[pkteison]

Can somebody try to explain what considerations go into picking between merge and rebase, or when rebase is a better option? The example here "you've branched that file and made some changes. Meanwhile, someone else has modified that same file on the master branch..." says 'merge' to me, and I'm not sure what consideration goes into the decision that rebase is the right tool instead. I've tried to google a bit, and read some posts on it on stack overflow, and it still just doesn't click for me.

[newishuser]

You rebase to clean up your own, non-shared, local commit history. That is it. As soon as your commits are shared you can no longer rebase them or feel the wrath. If you don't care about cleaning up your local history, before you share it, then don't rebase.

A merge creates a new commit that doesn't effect history so it's always safe to merge.

[base698]

My simple rule is if I'm on my feature branch that no one else is working off of, then I rebase. If I am working on a shared feature branch I merge.

Another good use case for plain merge is to play Dr. Frankenstein, combining many feature branches not yet in the main line to give an impromptu demo or see how the automated tests are shaking out.