- November 8, 2017
-
Matthew F. Fox
- 4 min
Here we are, our 3rd post on Git – and it’s going to be a good one. Why, you ask? Because branching, that’s why. Branching is a feature that I mentioned toward the beginning of our first post, and I’m excited to get started so let’s jump right in!
Branching is a simple, yet very powerful, feature of Git. Most tutorials get a bit overly technical and explain how branching works. Instead, we’re going to review what branching does for you as a developer. Branching is a way to create a unique set of changes to your codebase, separate from your master branch. This means that you can write new code, make modifications, etc. without affecting your master branch – which you would likely deploy to a production environment for use by end users.
Up till now, we’ve been performing work on the master branch of our repo. To confirm this, we’ll use the git branch –a command:
The git branch command, when combined with the –a flag, will output a list of all branches in our repository. The asterisk next to “master” indicates that it is the currently active branch. The second line indicates that our remote is also named master.
If we intend on deploying our project (I’m referring to the demo repo we’ve been working with for the past couple of posts) to a production environment, we don’t want to risk deploying code that is still in development. In order to avoid this, we can create a new branch and dedicate it to development purposes.
We are going to use the git checkout command to create and check out the new branch.
As you can see from the screenshots, we’ve created the new development branch and have checked it out. That means any changes we make to the repository will be applied to the development branch instead of the master branch.
In order to demonstrate this, let’s make a change to the readme.md file:
Now that we’ve made a change (we changed “Brawndo. THE THIRST MUTILATOR.” to “Because Brawndo’s got electrolytes”,) we’ll commit it to the development branch and push the changes to Github:
There’s a lot going on here, including a small problem. If you’ve been reading our series of posts on Git, you should see that we’ve committed and pushed our changes as usual, but there’s a small problem – we don’t have a development branch in our Github repo.
Thankfully, Git is helpful in situations like this and tells you exactly what needs to be done. We simply have to push the current branch and set the remote as upstream. Once we’ve done so, our changes will be pushed to the development branch on Github:
Ok, all set. Now we have 2 branches, each with slightly different readme.md files. We can use the git checkout command to switch between the branches:
Since the two branches are separate from each other, you can continue performing work on the development branch without the concern that code that isn’t production-ready may be deployed when it shouldn’t.
When you are satisfied that the code you are working on in the development branch is stable, you can merge it back in to the master branch for deployment to a production environment:
To merge the contents of one branch in to another, be sure to checkout the branch that you want to merge in to, and then use the git merge command. In this case, we want to merge the development branch back in to master, so we use the git merge development command.
With the merge complete, the contents of the readme.md file in the master branch is now what we set in the development branch:
This was a really basic look at branching; it’s a very powerful feature and can make working in teams much less complex than without it.
At Valiant, we tend to take an approach similar to what I’ve described, with the addition of creating branches off of development that are feature-specific.
This allows our team members to concentrate on their own development tasks without conflict. When a feature has passed all tests in its own branch, it’s merged in to the development branch, and then when ready, the development branch is merged in to the master branch prior to deploying the new feature to the project’s production environment.
Stay tuned for our final post in this series – we’ll be spending some time making Git work even harder for you. Until next time!
