Branching in git and collaboration

Hi there! This article aims to explain what are git branches and how we use them for collaborating with our teammates, this will not be very exhaustive in terms of features that git offers, but will explain what we mostly use everyday, in other complicated cases StackOverflow comes to the rescue.

Photo by Roman Synkevych on Unsplash R❤

Now before we get started, I had earlier published an article explaining the basics of git and Github, it’s about setting up a repository, committing and other really basic stuff, check it out if needed.

We are good to go now.

What is a branch?
In simple words a git branch is a version of the repository which diverges from the main repository.
There is initially one branch in every git repository, it’s called main/master branch.
I will be using simple diagrams to give a visual representation of what we are doing to get a better understanding, one sample diagram is this,

master branch with two commits

When working on our personal projects, if we are using any version control software, we don’t give attention to creating branches and we tend to keep all our code in the default main/master branch, so we keep on creating new commits on the main branch and updating our code on the remote repository.

But consider working in a large team collaborating on a big project, you won’t be committing everything on the main branch, you might not even have access to commit or push to master branch in most cases, in that case we generally create a new branch from the main branch, work on the separate branch, write code, create commits and when we are done we get our branch merged in the main branch.

But how do we create these branches?
To create a new branch using git commands we use this,

git branch <branch_name>

this creates a new branch with the name that you provide, this must be unique and no other branch with the same name can exist, the branch name is the identifier of the branch, so it has to be unique.
This command just creates a new branch from the current state of the repository (whatever branch and commit you are on), you need to explicitly checkout to the new branch to actually move to that branch and start working on it, the command for that is

git checkout <branch_name>

Yes, that’s two steps, there is a shorthand also that combines creating a branch and moving to that branch, it is

git checkout -b <branch_name> 

// pay attention to the -b

This creates a branch from the current branch, if you need to create a new branch from some other branch there is an optional parameter you can provide, <source-branch-name>

git checkout -b <branch_name> <source_branch_name>

To delete a branch also there is a command,

git branch -d <branch_name>
// this is safe delete and deletes only if the branch is merged

git branch -D <branch_name>
// this deletes the branch without any safety

You can also rename the current branch using this command,

git branch -m <new_branch_name>

Now that you are on the new branch, you can work and commit on it, this makes the current state of our repository somewhat like this,

a new branch “feature/blue” created from the master branch after 2 commits on master, the feature/blue branch also has a commit

Merging
Let’s say it was a small feature and it’s completed with just a single commit and finally we need to get our branch merged into the master branch.
We can create pull requests to get our branches merged into the master branch, or if you have access to the master branch you can directly merge the feature branch into the master branch and publish the updated master branch to the remote repository.

There are basically two branches that we merge, one is called the source branch and one is called the target branch, source branch is the branch that we are merging and target branch is the branch that we are merging into.

Before creating a pull request or merging the source branch into the target branch, we should always pull the latest code from the target branch into our source branch, this is also a merge, but in the reverse order, we merge the target(master) branch into the source(feature/blue) branch first, this is done because there might be some changes in the master branch since we created the feature branch, and we should keep our feature branch updated with the latest code from master branch and to test our feature with the master branch’s changes or resolve any merge conflicts(more on these later)

The command that is used for merging is this,

git merge <branch_name>

This command merges the branch with <branch_name> into the current branch, making the current branch the target branch and <branch_name> the source branch, so for merging the master branch into the feature branch, the command is

git merge master

git does the merging(combines the changes of both branches).
The merge will need user intervention if there are some parts of files which were changed in both the branches, this is called a merge conflict, the user needs to specify which changes to keep, this is called resolving conflicts, after resolving the conflicts you need to make a commit, this will be the merge commit, and now the branches are merged. The image depicts the current state of the repository

feature/blue merged into master with a merge commit

Now if you have access to the master branch you can switch to the master branch, merge the feature branch into the master branch and publish the master branch to the remote repository

git checkout master
git merge feature/blue
git push origin master

If you don’t have access to the master branch, you can publish the merged feature branch to the remote repository and create a pull request where the repository is hosted(Github, Gitlab etc).

The merge command combines the commit history of both the branches, and a new merge commit is created on the target branch, the source branch remains unchanged.

There is an option in the merge command, which makes the merge work differently, its Squash merge

git merge --squash <branch_name>

this will take all the changes from the <branch_name>, squash them into a single commit and add that commit to the current branch (the target branch), this option does not preserve the commit history of the source branch in the target branch.

There is another way to collaborate or combine changes of two branches, its rebase, there is a command like git merge for this its git rebase

git rebase master

This is run when we are on the feature branch and what this does is, integrates changes from the master branch to the feature branch, and the git logs are modified once the action is complete.

Git rebase takes all the changes, and compresses them into a single patch and integrates this new patch onto the target branch. Then, it moves the completed work from one branch to another, typically the master branch. In the process, rebase flattens the history, removing unwanted entries. Rebase changes the commit history as it flattens it, while merge preserves the commit history.

After rebasing your feature branch and publishing it on the remote repository, you can create a pull request to get it merged into the master branch.

If there were multiple team members working on multiple features at the same time, the repository would look something like this

A bigger project repository with multiple features developed simultaneously in multiple branches

The article has been long as it is, will be back in a new one with details on forks and merging strategies. Thanks for your time, hope it was helpful. ❤