本文将介绍一种 Git 企业工作流规范,git-flow 工作流。它定义了一个围绕项目发布的严格分支模型。

git-flow 的工作方式

git-flow 工作流仍然用远程远程仓库作为所有开发者的交互中心,和其它的工作流一样,开发者在本地工作并 push 推送分支到远程仓库中。

主分支/开发分支 master/develop

相对使用仅有的一个 master 分支,git-flow 工作流使用2个分支来记录项目的记录。 master 分支存储了正式发布的记录,而 develop 分支作为功能的集成分支。这样也方便 master 分支上的所有提交分配一个版本号。

功能分支 feature

每个新功能就是一个新的功能分支,功能分支可以 push 到远程仓库以备份和协作,新功能分支是从 develop 分支上拉出创建的新分支。当新功能完成时,合并回 develop 分支,新功能提交应该从不直接与 master 分支交互。

1
2
3
4
5
6
7
8
9
10
11
12
13
# 切换到develop分支
git checkout develop

# 创建新的功能分支,研发新的功能
git checkout -b feature_new_code

# 提交代码
git add .
git commit -m '新的功能开发'

# 功能完成合并到develop分支
git checkout develop
git merge feature_new_code

发布分支 release

当有新的功能发布或到了约定的代码发布日时,就需要从 develop 分支上 fork 一个发布分支,新建的分支用于开始发布循环,从这个时间点开始之后新的功能将不能再加到这个分支上,这个分支只做当前版本修改,bug 修复,文档生成以及对外发布。一旦发布的工作都完成了,将此发布分支合并到 master 分支,并分配一个版本号打Tag。重点说明下,这个分支上的修改要合并回 develop 分支。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 切换到develop分支
git checkout develop

# 创建新的功能分支,用于发布分支
git checkout -b release_new_tag

# 合并功能分支到发布分支
git checkout release_new_tag

# 特殊说明,合并分支前要先拉取代码
git pull
git merge --no-ff feature_new_code

# 正式发布
git checkout master
git merge --no-ff release_new_tag
# 打 Tag
git tag -a v1.1.0 -m "new version v1.1.0"

# 合并代码到develop
git checkout develop
git merge --no-ff release_new_tag

维护分支

维护分支或者热修复 (hotfix) 分支,用于生成快速给已发布版本打补丁,是专门为了修复bug创建的分支,这是唯一可以直接从 master 分支 fork 出来的分支,当修复完成后,修改应该马上合并回 master 分支和 develop 分支,master 分支应该用新的版本号打好 Tag。
为 Bug 修复使用专门分支,让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。你可以把维护分支想成是一个直接在 master 分支上处理的临时发布。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 切换到master
git checkout master
# 创建bug修复分支
git checkout -b hotfix_new_bug_code

# 修复bug后提交
git add .
git commit -m '修复bug'

# 切换到master并合并 bug修复分支
git checkout master
git merge --no-dd hotfix_new_bug_code
# 打 Tag
git tag -a v1.1.1 -m "fix bug"

# 切换到master并合并 bug修复分支
git checkout develop
git merge --no-dd hotfix_new_bug_code

相关工具和参考文件