Featured Image: “Forest” by fear-sAs is licensed under CC BY-NC-ND 3.0

In my previous post we looked at some basic git commands. Let us delve a little deeper into branches.

Git Branch

A branch in git is really just a pointer to a commit

Image from git docs shows master and testing are two branches that are currently pointing to the same commit

Head points to the current branch which in turn points to the latest commit in a branch.

screenshot of a git status

Same image as earlier but now with reference to HEAD - For nore details refer Git Branching Branches in a Nutshell

Integrating changes between branches

Two main ways to get changes from branch to another.

  • Merge
  • Rebase


As more people start working in the same project, there will be multiple contributions made throughout the day. All these will be done from individual branches and we have to get all the changes in those individual branches into the main repository’s main branch, usually named master (main these days).

while person x was working on iss53, person y got a hotfix ready to go on top of master

Now if the pull request was accepted and hotfix merged into master/main. But you are still working on iss53.

Three snapshots used in a typical merge

Finally you create a pull request after you have completed working on iss53, this has to now go into master as a merge-commit.

Merging iss53 into master, makes a merge-commit c6, which has two parent branches!

That’s a merge operation in action.


  • Common scenario:
    • Working on a feature for more than a day while others have committed and merged to master
    • So you want your feature to be the last one on master
You were working on experiment branch, based off of master at c2. Someone merged C3 into master. Now your experiment branch, needs latest master functionality. so you rebase experiment onto master, creating a linear history of changes in experiment!

When not to rebase?

  • Rebasing abandons commits and creates new ones that are similar but different
  • If you are collaborating on a feature and sharing the same branch with another person
  • Do not rebase until both sides have completely merged changes into the common branch
  • If you rebase and push in between, you are killing collaboration
  • Every time you rebase and (force) push, you create new commits that didn’t exist in the collaborators’ local branch, forcing your fellow collaborator(s) to murder you or quit and move on. Okay that’s a bit extreme, but you know.

Interactive rebase

This is how you do a rebase interactively on the command line.

The options available to you when you run an interactive rebase

Quite often when you are doing a rebase onto a main branch, you would want to squash your commits. Squashing means, combining several commits into one so that your changes don’t look like a mega list of changes. You would want to do this in order to make your main branch’s history look concise.

Nobody wants to know how many times you missed a semi-colon or a comma. However, most people would want to know a one-line description of what feature went into main branch.

Gives a really good summary of the options available to you and explains rebasing in detail.

Git Branching and Rebasing documentation gives a really good summary of the options available to you and explains rebasing in detail.

Let us learn more about some additional helpful commands that could save you from tricky situations in the next post.