Git merge lets you bring the changes from one branch, on to the other. Merge replays the changes in a branch on top another, starting from the commit where the two branches last diverged. Lets take for instance 2 different branches.
– staging
1 2 3 4 5 |
commit A commit B commit C |
– live
1 2 3 4 5 6 7 |
commit A commit I commit J commit K |
to merge the the staging branch on to the live branch, you need to:
1 2 3 |
git checkout live git merge staging |
This will replay the changes made in the staging branch, on top of the live branch at the point where their history last diverged. In this example, both branches diverged from commit A and staging will apply all of its commit snapshots on top of the live branch til the most recent staging snapshot, which is commit C.
Merge will record this replay in a brand new commit along, with the names of the two parent commits and the change log.
git rebase vs merge
Rebasing for a fact creates a cleaner history than merge. The history of a rebased branch consists of a series of linear commits even though the actual work may have happened in parallel. The end result of a merge and rebase will always be the same as they both point to exactly the same diffs, but only the recorded history of snapshots being the difference. Merge always create an additional commit on top of the existing snapshots being brought forward, and also its replay of snapshots on the target branch is not linear.
