Merging is (as the name suggests) a merge of all the commits on branch A that branch B doesn't have, into branch B. By merge I mean: try to incorporate the changes from the source branch into the target branch as "harmoniously" as possible and create a new commit to signify that the merge happened. Merging is generally considered a safe operation because it doesn't modify anything that came before it— it's creating a new commit to describe the merged in changes without affecting the histories of either branch.
Rebasing is an altogether more complex beast so do forgive me if I get a little verbose in my explanation... Think of rebasing as modifying the history of a branch by inserting commits that happened on another branch into the target branch's history. Picture that branch A is the parent branch that branch B originated from at commit A0. Then some commits occurred on branch A, let's call them: A1, A2, A3. Some commits also occurred on branch B: B1, B2, B3. Now we want to rebase B onto the tip of A (the tip being A3), meaning we want to replay all of the commits of B onto the tip of A, effectively rewriting B's history to make it originate from A3 instead of A0. Here's a before and after:
A0 - A1 - A2 - A3
\ - B1 - B2 - B3
A0 - A1 - A2 - A3
\ - B1 - B2 - B3
Now that we've rewritten branch B to look like the second example, all of B's commits are now based on A3, which includes all of the changes that branch A has up to A3.
On a personal note, I feel merging is almost always the better of the two to go with when it comes to introducing changes from one branch into another, purely because it's safer to do and the merge operation is tracked in git's history. Rebasing can be a very powerful tool once you get used to using it, but beware: you're rewriting history! I've seen enough sci-fi movies to know that's a very bad idea. Joking aside— rebasing doesn't create a new commit so the change isn't tracked in git. Be absolutely 100% sure that you know what you're doing before rebasing a branch. And if you don't know for sure, stick to merging.
This recent Medium article also highlights the potential for bad things to happen during a rebase and will explain rebasing better than I just did (with nice pictures too!)
Aaron Cooper
UK Software Engineer in Singapore
Here's how I like to think of the two:
Merging is (as the name suggests) a merge of all the commits on branch A that branch B doesn't have, into branch B. By merge I mean: try to incorporate the changes from the source branch into the target branch as "harmoniously" as possible and create a new commit to signify that the merge happened. Merging is generally considered a safe operation because it doesn't modify anything that came before it— it's creating a new commit to describe the merged in changes without affecting the histories of either branch.
Rebasing is an altogether more complex beast so do forgive me if I get a little verbose in my explanation... Think of rebasing as modifying the history of a branch by inserting commits that happened on another branch into the target branch's history. Picture that branch A is the parent branch that branch B originated from at commit A0. Then some commits occurred on branch A, let's call them: A1, A2, A3. Some commits also occurred on branch B: B1, B2, B3. Now we want to rebase B onto the tip of A (the tip being A3), meaning we want to replay all of the commits of B onto the tip of A, effectively rewriting B's history to make it originate from A3 instead of A0. Here's a before and after:
A0 - A1 - A2 - A3 \ - B1 - B2 - B3A0 - A1 - A2 - A3 \ - B1 - B2 - B3Now that we've rewritten branch B to look like the second example, all of B's commits are now based on A3, which includes all of the changes that branch A has up to A3.
On a personal note, I feel merging is almost always the better of the two to go with when it comes to introducing changes from one branch into another, purely because it's safer to do and the merge operation is tracked in git's history. Rebasing can be a very powerful tool once you get used to using it, but beware: you're rewriting history! I've seen enough sci-fi movies to know that's a very bad idea. Joking aside— rebasing doesn't create a new commit so the change isn't tracked in git. Be absolutely 100% sure that you know what you're doing before rebasing a branch. And if you don't know for sure, stick to merging.
This recent Medium article also highlights the potential for bad things to happen during a rebase and will explain rebasing better than I just did (with nice pictures too!)