Git Branching for beginners

Not this kind of branch.

If you’ve never dealt with a version control system before, the concept of branching may be entirely foreign to you. In Git, you start off with a “master” branch, which you are entirely able to directly commit all of your work to. However, this is generally not recommended, and if you do this, you’re missing out on a lot of the power a system like Git offers. Especially if you’re planning on collaborating with anyone else, branching will become an important part of your life. If you’re starting your own project from scratch, what you’ll want to do, is create a branch off of your master branch, immediately after your first commit. Call this whatever you like, but conventionally, this should be something like ‘develop’, ‘development’, or simply ‘dev’. If you’re joining a team, this will most likely have already been done before you join. The command to create a new branch goes like this (replace the bracketed text with your branch name):

git checkout -b <branch_name>

git checkout is ordinarily used to switch branches, but by adding the -b flag, you’re telling Git to create the branch you’re naming.

When you make a commit to this new branch, it will not be available on the base branch until your new branch has been merged. Change a file on your develop branch, commit your work with the message ‘WIP’ (NEVER actually commit ‘WIP’ to a branch you’re going to share, this is for demonstration purposes only): git commit -m 'WIP'.

When you run the command git log, you should be able to see your new commit along with the commit SHA, and some information about the branch.

Below: `origin/master` denotes the base remote branch (in red), with `master` (in green) being the local base branch. Above: `HEAD` in teal represents the start of the branch, `develop` in green is the local branch name.

To push your branch up to your remote origin, you’ll want to ensure that the first time you do so, utilize the -u flag to denote which branch you want to track as your remote:

git push -u origin <branch_name>

Upon successfully pushing to your new remote origin, you should see something like this. Your prompt may not look as cool as mine. I use Oh My Zsh! to customize it to show the directory I’m in, which branch I’m on, Git branch status, and current (short) commit SHA.

If you switch back over to your master branch using the command git checkout master, and then check the log using git log, you should see something like this:

Note your commit from the develop branch will not show up here.

To merge your new changes to the master branch, you can use the command:

git merge <branch_name> , which should give you a result like this:

Here, we’re merging `develop` branch into `master`

`git log` results. Notice the commit from `develop` branch now shows up.

Notice in the merge screenshot there’s an up-arrow with a 1 next to the branch name? This denotes that the local branch is ahead of the remote branch by one commit. (I realize I should have explained this earlier when I was pushing up the develop branch, but I forgot to screenshot it before I pushed it up.) Again, this is not a standard thing you’ll see in your prompt, to get it, you’ll need to install zsh, an Oh My Zsh! prompt theme that supports it, and a NerdFont for your terminal that supports icons. I may make this the subject of another post. I mention it only to denote that we need to push our changes to our remote. We’ll do so with this command: git push

And now your remote branches are all caught up! Of course, this over-simplifies the process… in practice, you’ll want to create a branch off of your develop branch for each new feature or bug-fix, in order to keep your working code clean while you’re writing new code. When working with others, when you’re ready for your code to be merged into your base branch, you’ll issue a pull-request and get your colleagues to review prior to the merge. All feature and bug branches should be merged to the develop branch, which in turn should be merged to your master branch after reaching a pre-determined release milestone (professionally, this would happen after you’ve submitted your work to be tested by your QA — these releases tend to contain many new features and/or bug fixes at a time).

Finally, you can view a neat-looking graph of your branch history with this command: `git log --all --decorate --oneline --graph , which will give you an output that looks something like this:

I had done some changes to my README.md file online through Github’s interface, and so had to pull `origin/master` before I could push, that’s why my history looks the way it does here.

Properly utilized, Git branches are a powerful tool to keep your work-in-progress on various features segregated from code that may currently be in use. Branches enable you to develop and test new features and bug-fixes independent of code that may already be in use in a production environment, which will help to prevent you from introducing regressions or new bugs into your codebase.