Git Branching

So-called Git’s killer feature


Dhayaalan Raju

3 years ago | 4 min read

What is Branching?

Branching means you diverge from the main-line of development and continue to do work without messing with that main-line.

Git’s Branching model is referred to as it’s “killer feature” because the way Git branches are incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches is faster.

A branch in Git is simply a lightweight movable pointer to one of the commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch pointer moves forward automatically.

The Topics covered are

  1. Creating a New Branch
  2. Switching Branches
  3. Merging
  4. Deleting a Branch
  5. Merge Conflicts
  6. Branch Management
  7. Rebase

1. Creating a New Branch

The command to create a new branch is git branch

$ git branch <branch name>

What this command does is, it creates a new pointer to the same commit you’re currently on.

Now you might get a question “How does Git know what branch I am currently working on?”

There is a special pointer called HEAD, which points to the local branch you’re currently on.

2. Switching Branches

To switch to an existing branch the command is git checkout

$ git checkout <existing branch name>

This moves HEAD to point to the <existing branch> branch.

There are few things to be noted here,

When you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed to that branch.

When you create and switch to a branch, do some work on it, and then switch back to your main branch and do other work in the main branch, both of these changes are isolated in separate branches. You can switch back and forth between the branches and merge them together when you’re ready.

Everything mentioned above is just done with a simple branch, checkout and commit commands.

Creating a new Branch and Switching to it at the same time:

$ git checkout -b <branch name>

This is shorthand for:

$ git branch <branch name>
$ git checkout <branch name>

3. Merging

If you need to merge your current branch with the desired branch, first check out the branch you wish to merge into and then run the git merge command.

$ git checkout master
$ git merge <branch name>

here master is considered as the desired branch.

4. Deleting a branch

Since our work is merged in we have no further need for that branch. So we can delete it using this command

$ git branch -d <branch name>

5. Merge Conflicts

If you change the same part of the same file differently in the two branches you’re merging, You will get a merge conflict. If you want to see which files are unmerged after a merge conflict, run the git status command.

Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts.

In order to resolve the conflict, we can either choose one side or the other or merge the contents ourselves.

After resolving run git add on each file to mark it as resolved.

If you want to use a graphical tool to resolve these issues, you can run this command:

$ git mergetool

This command fires up an appropriate visual merge tool and walks you through the conflicts.

6. Branch Management

These Branch Management Tools will come in handy when we use branches all the time

$ git branch

Running this command without any arguments will list your current branches

The * character prefixes the branch that you currently have checked out (i.e., the branch that HEAD points to).

To see the last commit on each branch, run this command

$ git branch -v

To see the list of branches that are already merged into the current branch, run this command

$ git branch --merged

Branches on this list without * in front of them are fine to delete since we already merged their work into another branch.

To see the list of branches that are not merged in, run this command

$ git branch --no-merged

Trying to delete the listed branches here will result in a failure. However, if you want to delete a branch and lose its work, you can force it with this command

$ git branch -D <branch name>

7. Rebasing

There are two ways to integrate changes from one branch into another-merge and rebase. Let’s see the difference between merge and rebase.

In merge a three-way merge between the two latest branch commits and the most recent common ancestor of these two branches is done.

$ git checkout master
$ git merge <branch name>

Now you can delete the branch

$ git branch -d <branch name>

In rebase it’s just done with the master and the branch. The change introduced in the branch is reapplied on top of the master(or any other branch)

$ git checkout <branch name>
$ git rebase master
$ git checkout master
$ git merge <branch name>

Now you can delete the branch

$ git branch -d <branch name>

Both have the same result. The difference is rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.

The log of a rebased branch appears that all the work happened in a series, even when it originally happened in parallel.

The Drawbacks of rebasing can be summed up in a single sentence

Do not rebase commits that exist outside your repository and that people may have based work on.

When you rebase, you’re abandoning existing commits and creating new ones that are similar but different. Now you might get this question.

Which one is better Rebase or Merge?

The answer can be simple.

The repository’s commit history is a record of what actually happened. If this is important for your project then use the merge.

On the other hand, The repository’s commit history is the story of how your project is made. If you think these need to be cleaned up when sharing then use rebase.

The best way is to rebase local changes you’ve made but hasn’t shared yet before you push them in order to clean up your story, but never rebase anything you’ve pushed somewhere.

To learn the basics of git click here


Created by

Dhayaalan Raju

iOS Developer at Ivy Mobility







Related Articles