Introduction to Git Branching Strategies

Git branching allows developers to diverge from the production version of code to fix a bug or add a feature. Developers create branches to work with a copy of the code without modifying the existing version. You create branches to isolate your code changes, which you test before merging to the main branch (more on this later).

There is nothing special about the main branch. It is the first branch made when you initialize a Git repository using the git initcommand.

When you create a commit, Git identifies that snapshot of files with a unique SHA-1 hash. When you initially create a branch, Git creates a new pointer to the same commit the main branch is currently on.

How it works

A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.

The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.

Create Branches

When you create a branch, all Git needs to do is create a new pointer, it doesn’t change the repository in any other way. If you start with a repository that looks like this:

Then, you create a branch using the following command:

git branch crazy-experiment

The repository history remains unchanged. All you get is a new pointer to the current commit:

Note that this only creates the new branch. To start adding commits to it, you need to select it with git checkout, and then use the standard git add and git commit commands.

Create remote branches

So far these examples have all demonstrated local branch operations. The git branch command also works on remote branches. In order to operate on remote branches, a remote repo must first be configured and added to the local repo config.

$ git remote add new-remote-repo https://bitbucket.com/user/repo.git 
# Add remote repo to local repo config 
$ git push <new-remote-repo> crazy-experiment~ 
# pushes the crazy-experiment branch to new-remote-repo

This command will push a copy of the local branch crazy-experiment to the remote repo ＜remote＞.

Delete Branches

Once you’ve finished working on a branch and have merged it into the main code base, you’re free to delete the branch without losing any history:

git branch -d crazy-experiment

However, if the branch hasn’t been merged, the above command will output an error message:

error: The branch 'crazy-experiment' is not fully merged. If you are sure you want to delete it, run 'git branch -D crazy-experiment'.

This protects you from losing access to that entire line of development. If you really want to delete the branch (e.g., it’s a failed experiment), you can use the capital -D flag:

git branch -D crazy-experiment

This deletes the branch regardless of its status and without warnings, so use it judiciously.

The previous commands will delete a local copy of a branch. The branch may still exist in remote repos. To delete a remote branch execute the following.

git push origin --delete crazy-experiment

Or

git push origin :crazy-experiment

This will push a delete signal to the remote origin repository that triggers a delete of the remote crazy-experiment branch.

Git Branches Strategies

A branching strategy is the strategy that software development teams adopt when writing, merging and deploying code when using a version control system. It is essentially a set of rules that developers can follow to stipulate how they interact with a shared codebase.

The branches protect the mainline of code and any changes made to any given branch don’t affect other developers. Such a strategy is necessary as it helps keep repositories organized to avoid errors in the application and the dreaded merge hell when multiple developers are working simultaneously and are all adding their changes at the same time.

Need for branching Strategies:

• Enhance productivity by ensuring proper coordination among developers

• Enable parallel development

• Help organize a series of planned, structured releases

• Map a clear path when making changes to software through to production

• Maintain a bug-free code where developers can quickly fix issues and get these changes back to production without disrupting the development workflow

Common Git branching strategies

1. GitFlow

GitFlow enables parallel development where developers can work separately from the master branch on features where a feature branch is created from the master branch.

This branching strategy consists of the following branches:

• Master

• Develop

• Feature- to develop new features that branches off the develop branch

• Release- help prepare a new production release; usually branched from the develop branch and must be merged back to both develop and master

• Hotfix- also helps prepare for a release but unlike release branches, hotfix branches arise from a bug that has been discovered and must be resolved; it enables developers to keep working on their own changes on the develop branch while the bug is being fixed.

GitFlow Pros

1. It allows for parallel development to protect the production code so the main branch remains stable for release while developers work on separate branches.

2. Easier for Developers to organize their work.

3. Handling multiple versions of production code.

Gitflow Cons

1. As more branches are added, they become difficult to merge as developers merge their changes from the development branch to the main.

2. When the tests fails, it become difficult to figure out where the issue is.

3. Due to GitFlow's complexity, it could slow down the development process and release cycle.

4. Not efficient approach for teams to implement continuous integration and delivery.

2. GitHub Flow

GitHub Flow is a simpler alternative to GitFlow ideal for smaller teams as they don’t need to manage multiple versions. Unlike GitFlow, this model doesn’t have release branches. You start off with the main branch then developers create branches, feature branches that stem directly from the master, to isolate their work which are then merged back into main. The feature branch is then deleted. The main idea behind this model is keeping the master code in a constant deployable state and hence can support continuous integration and continuous delivery processes.

GitHub Flow pros

1. It is fast and streamlined branching strategy with short production cycles and frequent releases.

2. Allow fast feedback loop for identifying issue and resolve them quickly.

3. Since there is no development branch as you are testing and automating changes to one branch which allows for quick and continuous deployment.

GitHub Flow cons

1. Suited for small teams and web applications and it is ideal when you need to maintain a single production version.

2. This strategy is not suitable for handling multiple versions of the code.

3. Lack of development branches makes this strategy more susceptible to bugs and so can lead to an unstable production code

3. GitLab Flow

GitLab Flow is a simpler alternative to GitFlow that combines feature-driven development and feature branching with issue tracking. With GitFlow, developers create a develop branch and make that the default while GitLab Flow works with the main branch right away.

GitLab Flow is great when you want to maintain multiple environments and when you prefer to have a staging environment separate from the production environment. Then, whenever the main branch is ready to be deployed, you can merge back into the production branch and release it. Thus, this strategy offers propers isolation between environments allowing developers to maintain several versions of software in different environments.

4. Trunk-based development

Trunk-based development is a branching strategy that in fact requires no branches but instead, developers integrate their changes into a shared trunk at least once a day. This shared trunk should be ready for release anytime. The main idea behind this strategy is that developers make smaller changes more frequently and thus the goal is to limit long-lasting branches and avoid merge conflicts as all developers work on the same branch. In other words, developers commit directly into the trunk without the use of branches.

Consequently, trunk-based development is a key enabler of continuous integration (CI) and continuous delivery (CD) since changes are done more frequently to the trunk, often multiple times a day (CI) which allows features to be released much faster (CD).

This strategy is often combined with feature flags. As the trunk is always kept ready for release, feature flags help decouple deployment from release so any changes that are not ready can be wrapped in a feature flag and kept hidden while features that are complete can be released to end-users without delay.

Trunk-based development pros

1. Developers have better visibility over what changes other developers are making as commits are made directly into the trunk without the need for branches.

2. This does not require branches, this eliminates the stress of long-lived branches and merge conflicts.

3. Easy to resolve any conflicts that arise.

Trunk-based development Cons

1. Suited to senior developers as this strategy offers great amount of autonomy which non-experienced developers might find daunting as they are interacting directly with the shared trunk.

The Tech Platform

www.thetechplatform.com