All about merging and rebasing in Git

FORKED HISTORY

The Merge Option

Simply merge the master branch into the feature branch.

* — Merge Commit

Internal Working

Git internally takes two commit pointers, usually the branch tips, and will find a common base commit between them. Once Git finds a common base commit it will create a new “merge commit” that combines the changes of each queued merge commit sequence.

Types of Merge

Fast-Forward Merge

It can occur if a linear path exists from the current branch tip to the target branch tip. In order to combine the histories Git just has to move(fast-forward) the current branch tip up to the target branch tip.

Before Merge
After Merge

3-Way Merge

Scary? Common! It is called a 3-Way Merge as Git uses three commits to generate the merge commit — the two branch tips and their common ancestor. In this case a linear path does not exist between the two branch tips.

Before Merge
After Merge

The Rebase Option

Rebasing is really just moving a branch from one commit to another. Pulling in upstream changes with Git merge results in a superfluous merge commit every time. On the other hand rebasing is like saying ‘I want to base my changes on what everybody has already done’. Rebase helps to keep your git history cleaner and simpler.

Rebase feature on master

Internal Working

Rebasing is changing the base of your branch from one commit to another making it appear as if you’d created your branch from a different commit. Internally, Git accomplishes this by creating new commits and applying them to the specified base. In this process a temporary branch is created that is a copy of the master branch(here). It’s very important to understand that even though the branch looks the same, it’s composed of entirely new commits. The commits have a new hash but keep their original date which might be a bit confusing since in the final branch the commits in purple are created earlier than the ones in blue. Rebasing is used to maintain a linear project history. After rebasing it appears as if you’ve been working off the latest master branch.Rebasing gives the later benefit of a clean merge of your feature branch back into the master branch. Rebasing is beneficial as it helps in debugging using git log because of the linear project history.

Golden Rules Of Rebasing

Don’t rebase public history or branches

We should never rebase commits once they’ve been pushed to a public repository. The rebase would replace the old commits with new ones and it would look like that part of your project history got deleted.

Commiting when remote branch changes

If you commit to a branch, but that branch changes at the same time on a remote machine, you can use rebase to shift your own commits, allowing you to push your commits to the remote repository.

Conclusion

You have two options for integrating your feature into the master branch:

  1. Merging directly which results in a 3-way merge and a merge commit.
  2. Rebasing and then merging which results in a fast-forward merge and a perfectly linear history.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aditya Sharma

Aditya Sharma

Building CRED | Open Source @Google Summer of Code, MLH | Research @Queens, Canada | Google Open Source Peer Bonus winner