Let’s Git Familiar — Part 3: Git Workflows

This story is the third part of a series on Git Version Control System Fundamentals. You can access to Part 1 of the series here, and to Part 2 of the series here.

In this part, I will introduce git workflows and explain their advantages and disadvantages in certain scenarios.

There are six widely used workflows when it comes to managing team projects. Some may be more suitable than others in certain situations. I will briefly explain their usages and talk about their pros and cons. Let’s git started!

1. Centralized (Basic) Git Workflow

In earlier days, the centralized version control systems like SVN were more popular. When distributed version control systems like Git became more widely used, people started to transition from SVN to those systems like Git. The Centralized Workflow simply follows the idea of a centralized version control systems such as SVN. It uses a central repository to serve as the single point-of-entry for all changes to the project. There is only one master branch and members push their local commits onto this branch and use it to deploy to the staging and production environment.

This image is taken from: https://zepel.io/blog/5-git-workflows-to-improve-development/

Pros

• It is easy to understand for a new learner or a recent SVN user
• If used properly there should not be any merge conflicts to deal with
• Easy to managed for small teams

Cons

• Hard to recover from any mistakes
• It gets complicated and messy to manage when the development team gets larger
• It limits the multiple task at the same time on the repository when it comes to bug fixes and deployments

2. Feature Branching Git Workflow

Centralized workflow is usually suitable for one or few developers working on the same project. Once your team of developers gets more then few people, it is better to stay away from centralized workflow. That is when the feature branching workflows comes into place. In feature branching workflow, a separate branch should be created for every feature of the project. The developers can implement their feature changes into their dedicated feature branches, and when they are done with the development, they can merge their respective feature branches to the main branch that the production code lives in. Ideally, a branch should have a lifespan of a few hours.

This image is taken from: https://zepel.io/blog/5-git-workflows-to-improve-development/

Pros

• The main branch always has finished code
• Makes it easy to develop and maintain features without disturbing the main branch

Cons

• When more than one developer work on the same feature it can get hard to manage the future branch
• If a future branch lifespan gets longer, it can make the merging difficult with a lot of conflicts

3. Trunk-based Development Git Workflow (Develop Branch)

Trunk-based Development Workflow (or Develop Branch Workflow) is similar to the feature branch workflow with a subtle change of using another branch called trunk (or develop). This branch is a parallel branch to the main (or master) branch, that is rebased from central repository when some features will be made to the next code release. Since it is rebased from main branch before a new feature is implemented, it acts as a working copy of the central repository. The changes from the feature branches are merged to the trunk branch first with resolving any conflicts that occurred during the process. The key part is, the release-ready code is tested again as a whole in this branch before merging it onto the main branch.

This image is taken from: https://zepel.io/blog/5-git-workflows-to-improve-development/

Pros

• The release-ready code is tested as a whole with all the new features added before merging with main branch
• Main branch is kept as clean as possible
• It allows to make minor and swift code changes without caring about breaking the main branch

Cons

• Adds complexity to the management of the repository with requiring extra steps
• Requires a developer to manage the conflicts locally
• Requires regular updates to make the main branch up to date

4. Personal Branching Git Workflow

Personal Branching Workflow is similar to feature branching. The only difference is, there is one branch per user instead of per feature. This allows developers have their separate branches to commit and do other actions more freely. Developers can use their own branch for small changes like bug fixes or implementing parts of the features they are responsible for. This workflow strategy is good for small teams in which every team member develops a part of the whole application.

Pros

• Developers can experiment more freely
• It makes the branch management easier since there is only one branch per team member
• Easy to implement small changes to the code like bug fixes etc.

Cons

• Does not give flexibility like feature branching when implementing big features
• If the application has a lot of features developing at the same time, this workflows makes repository management difficult

5. Forking Git Workflow

Forking Workflow is usually used for the projects in which a huge number of developers contribute. The best example for Forking Workflow is open-source projects like on GitHub. When a developer forks a project, a copy of the project is created as a separate repository in his/her account. That way, the developer can use his/her own server-side repository for the project instead of using only a single server-side repository as the central source of the project like other workflows. A remote path for the official repository is added to the repository that is cloned to the local system. Once the developer makes the changes to its copy repository, he/she creates a pull request to notify the original central repository owner to review the code changes and merge them if it is accepted.

Pros

• It is a great and secure way to manage the open-source project repositories
• The central repository owner has the full control of its code to merge only the high quality contribution
• Makes it easy to maintain the repository for large teams

Cons

• It is a longer process compared to the other workflows

6. Gitflow Git Workflow

Gitflow Workflow does not bring anything new to the table. It is very similar to Trunk-based Development Git Workflow with two additional branches, Release Branch and Hotfix Branch. As in Trunk-based development workflow, the main(master) branch is always releasable to the production code in Gitflow Workflow. Again, similar to Trunk-based development workflow, every feature is committed to the development(develop) branch.

The first difference is, when the team decides to publish a feature to the main branch, the developer first creates a release branch where testing and bug fixing occur before being merged back to the develop branch to make the develop branch as the latest source of the production code. After all the test are done and the code is secure enough to go to the production, then the release branch is merged to the main branch and the feature goes live.

The second difference comes to place when there is an urgent need for a swift bug fix to the production code. When the team requires a quick fix on the running code, a hotfix branch is created from the main branch, the required patch is applied on the code, and then it merges back to main branch directly. Only the Hotfix branch is created from and merged directly onto the main branch.

This image is taken from: https://zepel.io/blog/5-git-workflows-to-improve-development/

Pros

• The release branch makes the reviewing and conflict resolving process easier
• With the hotfix branch, it is easy and quick to make small bug fixings
• This workflow is great for large teams since it is secure and easy to manage

Cons

• The team should be careful when hotfixing since it can cause a problem directly to the production code
• It is a longer process compared to more basic workflow

I hope this article was helpful. This was the last part of the Let’s Git Familiar blog post series. You can check out the first and the second ones if you haven’t already. Stay healthy.