- Git workflows you can use to deliver better code and improve your development process
- By Vikash Koushik
- Translator: Chen Yuan
- Proofreader: HelloGitHub- Ya ya
I have yet to meet a developer who doesn’t scratch his head looking at conflicting information about Git branch merges.
Resolving Git merge conflicts is one of those things that every developer hates, especially if you’re preparing for a production deployment!
Setting up Git workflow correctly can improve your development process.
Of course, having the right Git workflow won’t solve all your problems. But it is a step in the right direction. After all, since each team works remotely, it is important to develop product features together without breaking the code base.
How you set up your Git workflow depends on the project you’re working on, the team’s release schedule, the size of the team, and so on!
In this article, we’ll introduce you to five different Git workflows, their pros, cons, and when to use them. Let’s get started!
1. Basic Git workflow
The most basic Git workflow is one branch – master branch. Developers directly submit the Master branch and use it to deploy to pre-release and production environments.
Above is a basic Git workflow where all commits are added directly to the Master branch.
This workflow is generally not recommended unless you are developing a side project and want to get started quickly.
Since there is only one branch, there is really no process. This way, you can easily get started with Git. However, there are some disadvantages to keep in mind when using this workflow:
- Collaborating on code leads to multiple conflicts.
- The probability of bugs in the production environment increases dramatically.
- Maintaining clean code is harder.
2. Git function branch workflow
Git branching workflows are mandatory when you have multiple developers working on the same code base.
Suppose you have a developer working on a new feature. Another developer is working on a second feature. Now, if two developers both commit to the same branch, this will throw the code base into chaos and cause a lot of conflicts.
Above is a Git workflow model with functional branches.
To avoid this, two developers can create separate branches from the Master branch and develop the functions they are responsible for. Once the functionality is complete, they can merge their branches into the Master branch and deploy instead of waiting for each other’s functionality to complete.
The advantage of using this workflow is that the Git feature branching workflow allows you to collaborate on code without worrying about code conflicts.
3. Branch Git workflow with Develop branch
This workflow is one of the more popular in development teams. It is similar to the Git functional branch workflow, but its Develop branch exists in parallel with the Master branch.
In this workflow, the Master branch always represents the state of the production environment. Whenever the team wants to deploy code to production, they deploy the Master branch.
The Develop branch represents the most recently delivered code for the next release. Developers create new branches from the Develop branch and develop new functionality. Once the functionality is developed, you test it, merge it with develop, test it with the develop code if you merge the other functionality, and then merge it with the Master branch.
Above is a Git feature branch workflow model with the Develop branch.
The advantage of this workflow is that it enables the team to consistently incorporate all new functionality, test it during the pre-release phase, and deploy it to production. While this workflow makes code maintenance easier, it can be a bit tiring for some teams, as frequent Git operations can get boring.
Gitflow workflow
The Gitflow workflow is very similar to the workflow we discussed earlier, and we use them in combination with the other two branches (the Release branch and the Hot-fix branch).
4.1 Hot Fix branch
The hot-fix branch is the only branch created from the Master branch and merged directly into the Master branch rather than the Develop branch. Use only when you must quickly fix production environment problems. One advantage of this branch is that it allows you to quickly fix and deploy problems in your production environment without interrupting someone else’s workflow or waiting for the next release cycle.
Once the fix has been merged into the Master branch and deployed, it should be merged into the Develop and current Release branches. This is done to ensure that anyone creating a new functional branch from the Develop branch has the latest code.
4.2 Release branch
After you have successfully merged all the code for the distribution-ready functionality into the Develop branch, you can create the Release branch from the Develop branch.
The Release branch does not contain code related to new functionality. Add only release-related code to the Release branch. For example, documents related to this version, bug fixes, and other associated tasks can only be added to this branch.
Once this branch is merged with the Master branch and deployed into production, it will also be merged back into the Develop branch so that when new functional branches are created from the Develop branch, the new branch will have the latest code.
Above is a Gitflow workflow model with hot-fix and release branches
First published by Vincent Driessen and very popular, this workflow has been widely used by organizations with scheduled release cycles.
Since git-flow is a wrapper around Git, you can install git-flow for your current code base. Git-flow is so simple that it doesn’t change anything in the code base other than creating branches for you.
To install on a Mac machine, run brew Install Git-flow in a terminal.
To install it on a Windows machine, you’ll need to download and install Git-Flow. Once installed, run the git flow init command to use it in your project.
Git Fork workflow
Fork workflows are popular among teams using open source software.
The process usually looks like this:
- Developers fork the official code base of open source software. Create a copy of this code base in their account.
- The developer then clones the code base from its account to the local system.
- Remote sources from the official code base have been added to the code base cloned to the local system.
- The developer creates a new functional branch, which is created in its local system, makes changes, and commits.
- These changes, along with branches, are pushed to a developer’s copy of the code base on their account.
- Create a pull request from the new feature branch and submit it to the official code base.
- The maintainer of the official code base checks the changes in the pull request and approves merging these changes into the official code base.
Your own workflow!
The Git workflows I describe in this article are examples of some of the most popular and best workflows in development teams. There are also teams that create a branch for pre-release, and that branch works well for them. So you can refer to these workflows and create your own Git workflow.
This article is translated using Breword, a free document translation tool that supports: machine pre-translation, visual editor, collaborative translation, proofreading, one-click document site generation, automatic monitoring of document updates, export, and more. To make translation easier, more efficient and maintainable, go for it!
Breword website: www.breword.com/
Translate open source project documents and articles to contribute to the open source community (subject: GitHub, programming, programmer). Welcome those who love technology and open source to join the translation series launched by HG, you can add wechat id: HelloGitHub (note: translation).