Introduction
This article is the third in the "Using Git" series. It assumes you have read both the installation article and the How to Use Git Effectively article.
In the world of version control systems, GIT is undoubtedly one of the best in terms of flexibility. It is very easy to learn the syntax and understand how git can best serve your workflow and environment.
This tutorial will teach you how to create two branches (master and development) and how to merge code from development to production.
A branch, at its core, is a unique series of code changes with a unique name. Each repository can have one or more branches.
By default the first branch is called “master”.
View Branches
Before creating new branches, we want to see all the existing branches. We can view all the existing branches by typing the following:
git branch -a
Adding “-a” to the end of the command tells GIT that we want to see all available branches, including those we don’t have in our local workspace.
The output will be similar to the following:
* master remotes/origin/master
The asterisk next to “master” in the first line of the output indicates that we are currently on that branch. The second line simply indicates that there is a single branch on our remote, named origin, also called master.
Now that we know how to view branches, it's time to create our first branch.
Creating Branches
As mentioned at the beginning of this article, we want to have a development and a production setup for our coding environment.
We want to treat the default "master" branch as our production and so we need to create a single branch for development or pre-production.
To create a new branch called develop, type the following:
git checkout -b develop
Assuming we don't have a branch called "development" yet, the output will be as follows:
Switched to a new branch 'develop'
In the case of a branch with that name already existing, GIT tells us:
fatal: A branch named 'develop' already exists.
You can move back and forth between your two branches using the git checkout command:
git checkout master
Or
git checkout develop
Assuming there is a branch you want to switch to, you will see output similar to the following:
Switched to branch 'master'
If you try to switch to a branch that doesn't exist, such as
git checkout nosuchbranch
Git tells you:
error: pathspec 'nosuchbranch' did not match any file(s) known to git.
Now that we have multiple branches, we need to make good use of them. In our scenario, we use our “development” branch to test our changes and the master branch to release them to the public.
To demonstrate this process, we need to go back to our development branch:
git checkout develop
Making changes to our development branch
In this branch, we create a new empty file called “develop.” It won’t exist there until we merge it into the main branch (in the next step).
touch develop
Just like in the previous tutorial, we need to tell git that we want to track this new file.
We can add the “develop” file by typing:
git add develop
The above set of commands creates an empty file called “develop” and adds it to GIT.
We also need to commit this file, which will append this file to the branch we are currently in, which is “development”.
git commit -m "develop file" develop
This file now exists in the development branch. As we are about to find out, it does not exist in the master branch.
First, we want to confirm that we are currently in the development branch. We can do this by typing:
git branch
The output should be similar to the following figure:
* develop master
We already understood that the star next to the branch name indicates that we are currently on that branch.
Running the “ls” command shows us that these two files exist:
lsThe output shows us that both of our files are found with the names “file” and “develop” respectively:
develop file
Merge code between branches
The interesting part happens after we switch back to our original branch, which we can do with the git checkout command:
git checkout master
To make sure we are on the main branch, we can type the following:
git branch
The output tells us which branch we are on, indicated by the asterisk.
develop * master
Upon running “ls” again, it appears that our new file is missing.
fileIt's not lost – it's in our development branch and we're in our main branch.
In our scenario, this file represents any changes to any file (or a completely new file) that has passed all the tests in our development branch and is ready for production. The process of moving code between branches (often from development to production) is known as a merge.
It is important to remember when merging that we want to be on the branch we want to merge into.
In this case, we want to merge from our development branch, where the “develop” file exists, to our master branch.
With this in mind, given that we are currently on the master branch, all we need to do is run the merge command.
One of the options we can pass to the merge command, “–no-ff”, means that we want git to keep all the commit messages before the merge. This makes it easier to track changes in the future.
To merge changes from the development branch into the master branch, type the following:
git merge develop --no-ff
The output of the command will be similar to the following:
Merge made by the 'recursive' strategy. 0 files changed create mode 100644 develop
Running the ls command again confirms that our “develop” file is now in our main branch.
develop file
The last thing we need to do now, to make this change to the remote server, is to push the changes, which we can do with the help of the git push command.
git push
You will see output similar to the following, confirming that you have merged from your development branch to the master branch on your remote server:
Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 332 bytes, done. Total 3 (delta 1), reused 0 (delta 0) To ssh://[email protected]/repository 9af2dcb..53649cf master -> master
Result
By following the tutorial above, you should have a two-branch workflow setup and hopefully have a good understanding of how branching works in GIT. Let us know what you think in the comments!
