Git is currently the most popular code management tool, and I believe everyone is using Git to manage their team's source code.
The team generally needs a more standardized Git workflow in order to standardize development, maintain good code submission records, and maintain a clear Git branch structure to facilitate subsequent maintenance.
This article was born under this background. If your team happens to have this need, you can take a look. I hope this article can provide you with some help to establish a good team code process specification.
The contents of this article are as follows
- Main advantages of Git
- Git branch management
- Git log specification
- Git Flow workflow
- Git Flow in action
Main advantages of Git
- Distributed storage, the local warehouse contains all the contents of the remote warehouse.
- The security is high, and you are not afraid of losing remote warehouse files.
- Excellent branch model, creating/merging branches are very fast and convenient.
Git branch management
In actual work, we will create many branches to facilitate development in different scenarios, but if there is no branch specification, it will cause branch clutter, and you often don’t know what a certain branch is doing. Let’s introduce what we commonly use. And recommend the type of branch you use.
Git branch type
master branch
- master is the main branch of the product. This branch is a read-only branch and is also used to deploy the production environment. The stability of the master branch needs to be ensured.
- The master branch is generally merged by the release branch or the hotfix branch. Under no circumstances should you directly modify the master branch code.
- After all the functions of the product are implemented, they will be finally released on the master branch. In addition, all pushes on the master branch should be tagged for records to facilitate traceability.
- The master branch cannot be deleted.
develop branch
- develop is the main development branch, which is created based on the master branch, and always keeps the latest code of completed functions and the code after bug fixes.
- The develop branch is a read-only branch, which can only be merged from other branches. It is not possible to do feature development or bug fixes directly on this branch.
- Generally, when developing new features, the feature branch is created based on the develop branch.
- The develop branch contains all the code to be released to the next release.
- After the feature branch is completed, the developer needs to merge to the develop branch (not push remote), first merge the develop branch to the feature, and then merge to the develop branch after resolving the conflict.
- After all the new features are developed and the developers have completed their self-tests, they will pull the release branch from develop for testing.
- After the release or hotfix branch is online, developers need to merge to the develop branch and push remotely.
- The develop branch cannot be deleted.
feature branch
- The feature branch is usually a new feature or a new feature development branch, and the feature branch is created based on the develop branch.
- Branch naming: new feature or new feature branch starting with feature/, suggested naming rule: feature/user_createtime_feature, for example: feature/ftd_20201018_alipay, meaning: developer ftd created an Alipay payment on October 18, 2020 Functional branch.
- After the development of new features or new functions is completed, developers need to merge to the develop branch.
- Multiple feature branches can exist at the same time, which are used for the simultaneous development of multiple features in the team.
- The feature branch is a temporary branch and can be deleted after the function is completed.
release branch
- The release branch is a pre-launch branch, which is created from the develop branch after all the feature branches that are currently online are merged into the develop branch.
- Branch naming: The branch that starts with release/ is the pre-launch branch. The recommended naming rule: release/version_publishtime, for example: release/v2.1.1_20201018, meaning: version number v2.1.1 is scheduled to be released on October 18, 2020.
- The release branch is mainly used to submit to testers for functional testing. During the release test phase, the test will be performed based on the release branch code. The bugs found in the testing process are fixed in this branch. After the online is completed, they need to be merged into the develop/master branch and pushed remotely.
- The release branch is a temporary branch and can be deleted after the product goes online.
After the development of a set of features is completed, first the developers will merge the latest feature code into the develop branch. When entering the testing phase, the development team leader creates a release branch on the develop branch.
If a bug needs to be fixed during the testing process, it is directly fixed and submitted by the developer on the release branch. When the test is completed, the development team leader merges the release branch into the master and develop branches. At this time, the master is the latest releasable code and is used for product release.
hotfix branch
- The hotfix branch is an online bug fix branch or patch branch, which is mainly used to fix bugs in online versions.
- Branch naming: The name at the beginning of hotfix/ is the repair branch. Its naming rule is similar to the feature branch. The recommended naming rule: hotfix/user_createtime_hotfix, for example: hotfix/ftd_20201018_alipaybugfix, meaning: the developer ftd created it on October 18, 2020 A branch of Alipay payment bug fixes.
- The hotfix branch is used when an emergency problem occurs online and needs to be repaired in time. Create a hotfix branch with the master branch as the baseline. When the problem is fixed, you need to merge to the master branch and develop branch and push the remote.
- All hotfix branch changes will go to the next release.
- The hotfix branch is a temporary branch and can be deleted after the bug fix is online.
The above are the 6 types of branches commonly used in work, covering common scenarios in development. You can also adjust them according to the actual work situation. The key is to let the team partners understand the types and functions of the entire branch.
The branch is created, and the friends have started to develop according to the process. However, due to the lack of constraints on the commit message in daily development, the content is random, the quality is uneven, the readability is low, and it is difficult to maintain. It is imminent to introduce the commit message specification into the project. A well-written commit message can greatly improve the efficiency of code maintenance.
Git log specification
In a team collaboration project, developers often need to submit some code to fix bugs or implement new features. The files in the project, what functions to achieve, and what problems to solve will gradually fade away, and finally you need to waste time to read the code. But the writing of a good log specification commit messages helps us, and it also reflects whether a developer is a good collaborator.
Well-written Commit messages can achieve 3 important purposes:
- Speed up the code view process
- Help developers write good version release logs
- Let future maintainers understand why specific changes and features are added in the code
Currently, the community has a variety of guidelines for writing Commit messages. The Angular specification is currently the most widely used writing method, which is more reasonable and systematic. The recommended use is as follows:
The basic syntax of Commit messages
The specific format is:
# EN
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
# CN
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
- type: The type of this commit, such as bugfix, docs, style, etc. See below for type description.
- Scope: The scope affected by this commit, such as the data layer, control layer, view layer, etc., varies from project to project.
- Subject: Explain briefly the subject of this commit, which is a short description of the purpose of the commit. It is recommended that it should not exceed 50 characters.
- Body: In the main content, we need to describe this commit in detail, such as the motivation of this change, the detailed modification method or other content that needs additional emphasis.
- footer: Describe the issue or break change associated with it, see the case for details.
Type description:
# 主要type
feat: 增加新功能
fix: 修复bug
# 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert: 执行git revert打印的message
# 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动
Commit messages format requirements
# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到issue地址或者其它文档
Example:
# fix：修复支付宝支付bug
#
# 1，修复支付完成后未查询支付状态问题
# 2，增加定时任务保证支付状态完整
#
# link：http://github.com/ftd/shopmall/issue001
Note: If there are many changes at one time and multiple submission types are included, it is recommended to split into multiple submissions and submit them in batches, which will be clearer.
Git Flow workflow
We have now learned about Git branches, including the types of branches, what types of branches are used under what circumstances, and the format specifications for submissions. However, often when a team has a large number of people and creates a large number of branches, it still brings a lot of troubles in branch operations. Is there a good process to regulate everyone? For these problems, I suggest you use the workflow mode of Git Flow.
Git Flow flowchart
1. The main branch process
- The master branch records the release history and tag tags of each version.
- The develop branch records the version history of all development.
- The develop branch is only pulled from the master branch when it is first created.
2. Development process
- The feature branch is a branch pulled from the develop branch.
- After each feature is completed, it needs to be merged into the develop branch.
3. Proposed test release process
- The release branch is a branch that is pulled from the develop branch after all the function development self-tests are completed.
- Once the release branch is created, it is usually no longer pulled from the develop branch. The branch only does bug fixes, document generation and other release-oriented tasks.
- After the release branch test is completed and the online standard is reached, it needs to be merged back into the master branch and the develop branch.
4. Bug repair process
- The hotfix branch is a branch pulled from the master branch after a bug appears online.
- After the hotfix branch test is completed, it needs to be merged back into the master branch and the develop branch.
Git Flow in action
After the process of Git Flow is clear, let's start the actual project combat. Assuming that we now have a mall project, and we have built a Git warehouse.
We show you how to use Git Flow workflow through the command line and graphical interface.
Git Flow command example
Start Feature
# 创建feature分支
git flow feature start ftd_20201018_wechatpay
# 指定当前分支pull的源为develop
git branch --set-upstream-to=origin/develop feature/ftd_20201018_wechatpay
Complete Feature
# 发布feature
git flow feature publish ftd_20201018_wechatpay
# 完成feature
git flow feature finish ftd_20201018_wechatpay
Start Release
git flow release start v1.0_20201031
Complete Release
git flow release finish v1.0_20201031
Start Hotfix
git flow hotfix start ftd_20201031_bugfix
Complete Hotfix
git flow hotfix finish ftd_20201031_bugfix
As you can see, more complex process management can be completed with a few simple commands. If you are not good at command lines, you can also use graphical tools. Sourcetree is recommended here. Sourcetree is also a well-known Git management tool. It greatly facilitates our operation and use of Git, let's introduce how to use Git Flow in sourcetree.
Note: The following content is an example of the Windows version of sourcetree, similar to Mac.
Initialize GitFlow
Open sourcetree, select the project that you want to use Git Flow workflow, and click the Git workflow button in the upper right corner, as shown below:
Then a dialog box will pop up, you can select product branch, development branch and function branch, as shown in the figure below:
Click OK to complete the Git Flow initialization of the warehouse.
Start Feature
Click the Git workflow in the upper right corner to display the interface as shown in the figure:
Enter the name of this feature, click OK to create the feature branch
You can see that there is a new feature branch locally, as shown in the figure:
Then you can start function development in this branch.
Complete Feature
After the function development is completed, click Git workflow in the upper right corner to display the interface as shown in the figure:
Click to complete the function, as shown below:
Here you can choose to delete or keep the feature branch, which can be processed according to the team's regulations.
After clicking OK, the feature function development is completed.
So far, the process is complete.
Start Release
Similarly, click on the Git workflow in the upper right corner and choose to create a new release version, as shown below:
Enter the release version name and click OK to complete the creation of the release branch.
At this point, you can see the release branch that has been created, as shown in the following figure:
Complete Release
After the test is passed, the release version can be released, as shown in the following figure:
Enter the label information for the release and click OK to release.
So far, we have completed the release process.
Hotfix
The hotfix process is similar to the above process operation method, so I won't repeat it again, you can practice the operation through the software.
Conclusion
Okay, here, we have finished all the content about Git workflow. You can use and improve it according to your team's needs to make team collaboration more efficient and standardized.
If you like this article,
Scan the QR code and follow the "I am a developer FTD" official account.
Follow the development and pay more attention to the developers!