Share an elegant way to play git workflow

在开发中，不论是一个团队一起开发一个项目，还是自己独立开发一个项目。都少不了要和git打交道。面对不同的开发场景，或许每个团队都有自己的git工作流。这里，我想分享一下我的团队目前正在使用的基于gitlab的git工作流。一起交流一下。

规范化的git流程能降低我们的出错概率，也不会经常遇到git问题，然后去搜一堆git高阶用法。我们的这套git玩法儿，其实只要会基本的git操作就行了，然后规范化操作，基本不会遇到git问题，这样大家就可以将时间用于业务上。最终，希望大家研究git的时候是在感兴趣的时候，而不是遇到问题，紧急去寻找答案的时候

我们的这种git工作流玩儿法呢，主要是分为下面几个分支：

• master分支   最新的稳定代码
• vx.x.x分支   版本分支，x.x.x是此次开发的版本号。
• feat-xxx分支 特性（新的功能）分支
• fix-xxx分支  修复分支

上面的这些分支呢，就是我们在开发中需要经常去创建并使用的分支。下面详细说说每个分支代表的意思。

master分支代表的是最新的稳定版本的代码，一般是版本分支或者修复分支的代码上线后合并过来的。

feat-xxx分支表示的是为开发某个版本的某个新功能而创建的分支。

vx.x.x represents the version branch. This is the branch we create from master under the name of this version number before the start of each version, such as version number is 2.0.1, then the version branch is v2.0.1. Then wait until the new features of this version are developed in feat-xxx and pass the smoke test, then go to gitlab to submit a mr and merge it into this version on the branch. After each environment test passes, merge the code of the version branch into master, and then delete this version branch.

fix-xxx represents the repair branch. Usually when dealing with online problems, a branch named after the defect name is created. After the defect test passes, mrMerge to the master branch to

Note: There is a detail here that the commit information submitted by development on the feature branch is generally considered to be useless information. When merging to the version branch, merge it into a commit (since we are using gitlab to merge, so check when initiating the mr request squash option will be fine), and after the test is submitted, whether it is to fix bugs during the test process or to optimize the function, all commit will be retained. This purpose is a warning, because I hope that the most The good situation is that the test is launched immediately. Although it is difficult to achieve this goal, the commit information left behind can help us review the

functions of each branch as described above. , then let’s talk about how to do some classic scenarios we developed:

The first scenario: normal development iteration

We take this time we need to develop a 1.0.0 version as an example. There are two functional modules, one needs to add a button, and the other needs to add a form

sequenceDiagram
master->>v1.0.0: 从master切出 v1.0.0
master->>feat-add-button: 从master切出 feat-add-button
master->>feat-add-form: 从master切出 feat-add-button
feat-add-form->>feat-add-form: 开发完成
feat-add-button->>feat-add-button: 开发完成
feat-add-button->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit
feat-add-form->>v1.0.0: 在gitlab发起mr到v1.0.0,并合并所有commit
v1.0.0->>v1.0.0: 提测
feat-add-button->>feat-add-button: 修复测试bug
feat-add-button->>v1.0.0: 将修复的 commit cherry pick到 v1.0.0
v1.0.0->>master: 在gitlab上mr到master，并将合并信息改成 v1.0.0

Through the above sequence diagram, you can see that we are about to start The version named a version branch v1.0.0, and also created two feature branches feat-add-button and feat- based on the two functions under this version. add-form, and then wait for the function development to be completed before initiating mr through gitlab (note that the mergecommit option must be checked here) to merge To v1.0.0, then the code of the v1.0.0 branch will start flowing from the dev environment to the production environment. Among them, if there is anything that needs to be fixed or optimized, the feature branch will be modified first, and then cherry pick will be moved to the version branch. After going online, delete the version branch and the following feature branches.

The code version managed through this process is very clear. This is a part of the intercepted master fragment.

There is another scene in the normal iteration process. That is, during the development process, PM suddenly came over and said that due to some kind of force majeure, a function needed to be cut off. At this time, if the code has not been tested yet, or the function is relatively simple, it is not too troublesome to deal with it. But if so, your function and the code of other colleagues have been tested, and some bugs have been fixed. The commits are all intertwined, especially the requirements that involve modifying many files, which will be very troublesome to deal with at this time. , not only do you have to look at other people's code, but you also have to be careful not to make mistakes in your own code. At this time, it is very simple in our process. Just delete the existing version branches, and then regroup the feature branches that need to be online. It can be seen that version branches are combined by feature branches, that is to say, version branches can be arbitrarily combined by different feature branches. This is more convenient to handle

The second scenario is online bug repair

We take the click event of a button that needs to be repaired online as an example

sequenceDiagram
master->>fix-button-click: 从master切出 fix-button-click
fix-button-click->>fix-button-click: 修复问题并测试
fix-button-click->>master: 从gitlab发起mr合并到master

In fact, the process here It’s not much different from the above, but what needs to be noted here is that when fixing online problems, one commit will be made for each bug, and the commits will not be merged when merging it into the master. And the merge information needs to be modified to this version number. For example, this time it is v1.0.1

The third scenario is multi-version parallel development

This scenario is no different from the normal iteration scenario, it just depends on whether you have multiple versions, so create The corresponding version branch is enough. Just follow the normal iteration process for each version branch.

Q&A

Q: Why are there no branches corresponding to the environment such as dev, test, etc., so that push and deployment can be achieved

A: Our process has given up using these Fixed branch. There are several reasons,

• After the code is tested, from dev to test, or even to uat (pre-release) environment, if there are code changes in different environments, then in order to keep the code of these branches consistent, it is necessary Synchronizing the code to each environment branch is a bit troublesome. This problem does not exist with version branches. There is only one version branch, which can correspond to various environments.

• Convenient for parallel development of multiple versions. Multiple version branches can be created, which is more convenient to deploy to different test environments during parallel development. If the modules between versions are not closely related, you can also test them in parallel.

• Semantic. Version branches can be used to know which branches are currently under development through the branch name.

Q: How to deal with changes in the master branch

A: If there are changes in the master branch, merge them into your own functional branch in a timely manner to prevent conflicts with other members' codes If there is a conflict

Recommended study: "Git Video Tutorial"