Branching in Git
In the first week of my internship at Mekansal İşler, we are given some Git topics to study and prepare a presentation. Mine was Branching.
Even though, I use git all the time for my personal projects and schoolwork, I was used to utilize only some basics properties of git. Despite the fact that I have technical knowledge on branching, I don’t use it daily, unfortunately. However, utilising branching even in small projects can help on managing that projects and also it can create a habit which can be useful on major projects in the future. So, I decided to use that presentation as an incentive to actively use branches and I suggest that to all.
For people who may want some information about branching and also as a reminder for myself, I will explain basics of branching. I know that there are a lot great resources and tutorials but this post also can help somebody. Who knows.
Let’s get started.
What is branching?
Actually, as the name suggests, you add a new development line to your project. Creating a branch is a great way to add new features, fix buges etc. without touching and damaging the main development line. You just do your thing in your branch and reunite when you are ready.
Default branch in Git is generally called the “master branch”. In the beginning, our HEAD pointer points to that branch. We can make HEAD point to another commit to work on another branch.
This is how you create a new branch and use it:
git branch myBranch //this creates a new branch called myBranch
git checkout myBranch //this changes your HEAD to myBranch
Also, it is possible to do these things in one command.
git checkout -b myBranch
Nice! Now we have a new branch and we can change some files in it. What happens after we did everthing we need to do in that branch? We would like to reunite our branch with our main line again. We merge two branches for that purpose.
git checkout master //changes our HEAD to master
git merge myBranch //merge myBranch with current branch(e.g master)
Git merges branch in two ways.
- Fast-forward Merge
- 3-Way Merge
If we have a linear branch, we can just move our Master pointer to the end of that branch. It is very intuitive.
However, if we have a nonlinear branch, we need to do something else.
If we have something like that, we can not just move the pointer of Master to other branch because the commits were differentiated at some point.
To solve this, git looks for the latest common ancestor of two branches and applies a diff from there. So it uses that common ancestor to reunite two brances and merges them into a new commit which called a “merge commit”
The purpose of rebasing is same with the merging. We want to combine our two branches.
git rebase <base> //e.g "git rebase master"
What rebasing does is putting the branch commits onto the base you selected. It does that by rewriting the history. So, previous commits are similar but modified to be able to rebase that branch.
I think it is very nice feature of git. It provides a very clean commit history. However, it also changes the history and there is actually a trade-off between clean line and detailed history.
Danger! You have to be careful if you are working with a remote repo. If you push your local and then rebase, it will cause an inconsistency. People who pulled your pushed commits will have a different base than the local base if you rebase.
So, this is a short introduction on branching. This can provide just the basic information about this topic. Atlassian and progit book provides very detailed and good tutorials. I suggest you to check them to get more information.