Basic Git Branching

In “Avengers: Endgame” , when Dr. Banner (Hulk) meets with Ancient one on the roof top and they discuss a different timeline in regard to infinity stone. That’s there, was branching in play, instead of source code, they were talking about time travel and alternate reality. Branching is a very useful topic in software version control and I believe mostly people are aware of this idea even if they are not from software development background.

Branching in Git is very powerful but same time can be overwhelming. Git branching covers a lot of workflows and scenarios and in this post I will try to introduce you with very basic setup and in most cases it would be enough and if needed you can later learn some advance techniques as well.

If you are new to Git, you can check my other post for a short introduction to Git on the following link and I will use same source code repository for this post as well.

https://hexquote.com/git-up-your-app/

Git branches are effectively a pointer to a snapshot of your changes.

Local Vs Remote Branch

In this post I will focus on local branches (the branches which live on your development machine), but the concepts are same for remote branches. Normally when you start developing a task, a bug fix or a new feature, you can create a new branch for that activity, do all your work in that branch, commit changes to that branch and once done, merge those changes back to master branch. So Lets start how we can start with this basic branching setup.

Step 1: Create a new local branch

The command >>git branch -v is one way to list all the branches for your repository. In our case we have only one “master” branch. Let say, we want to start now on a new feature in software which we call “feature1”, so what we can do is create a new branch for this feature as step 1 as below.

>>git checkout -b feature1: this command created a new branch named feature1 and make that branch our active branch.

Step 2: Code changes / commits etc/

Now, We develop our feature, make code changes , do commits etc. and all that happens in this feature branch. I am simulating this work by adding a text file called feature1 but that could be a whole bunch of files (HTML, CSS, JavaScript etc) and more stuff.

Step 3: Back to Master branch

Once you are done with your changes for feature1, you switch back to master branch.

>>git checkout master: command to switch to a branch.

optionally, it is also good if we execute >>git pull origin master to get any changes from the remote repository (just like mentioned in previous article).

Step 4: Merge the feature branch to master

Now, our changes are on feature1 branch and we have switched to master branch. we can use >>git merge feature1 and that will merge changes from feature1 branch to master.

Step 5: Delete the feature branch

Once we have successfully merged changes to master, we can delete our local branch and thats it. The whole purpose of this branch was to make code changes in isolation and once its done, we can delete with >>git branch -d feature1 command as follows:

Step 6: Push changes to Master (Remote)

This step is also optional, if we like, at this point we can push changes to master (remote), so other colleagues could pull these changes as well.

Summary

• >>git checkout -b feature1 (create a new branch called feature1)
• ………Code changes / commits here…… locally etc
• >>git checkout master (switch back to master branch)
• >>git pull origin master (pull changes from master, optional)
• >>git merge feature1 (merged feature1 branch back to master branch)
• >>git branch -d feature1 (delete the local branch after merge, optional)
• >>git push origin master (push changes to remote master, optional)

The above mentioned steps are all you need to start with git branching. I will suggest to adapt to this strategy for every code change, bug fix or new feature. Create a separate branch for that locally. It will simplify things for you a lot. Once you are comfortable, you can explore other advance areas of git branching. There is a nice article by Vincent Driessen, which allows you more control and cover some advance use cases, I will suggest that approach if you are dealing with complex workflows. You can access the article on https://nvie.com/posts/a-successful-git-branching-model/

If you need more information or if something is not clear, feel free to ask and I will try to answer. Till next time Happy Coding.

References

• https://www.atlassian.com/git/tutorials/using-branches