【技术博客】Git Flow模型管理代码版本

参考GIT版本管理：Git Flow模型，在此基础上加入了自己的理解，增加人员分工和相应代码，并根据本次项目的实际情况进行相应修改。

在本学期的软件工程开发过程中，我们从alpha阶段就使用了git flow模型进行git代码版本管理。鉴于我们的开发团队存在开发人数较少（7人）、任务周期固定（一次任务持续半周/一周）、成员各自任务之间关联性小、无需在版本发布前完成全面测试的特点，将传统的git flow模型进行了简化和实践。

本篇博客讲解我们使用的简化git flow模型，并提供了我们用到的所有指令代码，希望能给大家的开发带来帮助。本文不再去讲解最基础的代码提交、分支切换原理和流程。有任何错误或者疑问，可以在评论区指出和讨论～

完整git flow模型如图：

人员职责

开发者：所有人员都为开发者，可以对代码进行修改和提交。但开发者只允许从develop分支拉取个人feature分支后修改，commit后merge到develop中，而不允许直接改动develop分支，更不允许对master分支有任何操作。

版本管理者：本团队有1名版本管理者，负责在一次任务周期的最后阶段，所有人的提交全部merge到develop后，对master分支的相关操作，以更新master分支。

分支概述

远程分支

master：只有版本管理者有权利进行操作。简单地说，master上的每个版本都应该是相对稳定的版本，是每一次所有开发者的开发任务结束后留档的版本。

develop：每个开发者都可以从develop分支上拉取新分支，开发完成后合并到develop分支。

本地分支

master：连接远程master分支。

develop：连接远程develop分支。

feature：在一个任务周期中，从develop拉取，进行修改和提交。完成该周期的个人任务后，合并到develop分支，并将本地的feature分支删除。feature分支不允许提交到远程，即不允许在feature分支中出现push操作。feature分支以开发者名字简写命名。

release：在一个任务周期的最后阶段，所有人的提交全部merge到develop后，从develop分支拉取release分支，进行一定的测试。测试结束后合并到master和develop分支，并删除本地release分支。release分支以'release-x.x'命名，如‘release-0.9’，‘release-0.10’，‘release-1.0’等。release分支不允许提交到远程

一些约定

在每次add指令前，通过git branch查看分支是否正确。在每次git add .前，通过git status查看修改的文件。

具体操作

开发者

在一周的开发任务分配后，从develop创建自己的feature分支，以姓名简写命名：

任意分支下git checkout -b yourname develop

完成一部分开发任务后，提交代码：

git add filename
git commit -m "what have you changed"

注意并不push，即该分支只出现在本地。

重复上条，直到本次个人任务完成。提交到develop中：

git checkout develop
git pull origin develop       # 拉取远程develop代码到最新版本，防止merge出现冲突
git merge --no-ff yourname    # --no-ff不使用fast-forward方式合并，保留分支的commit历史
git push origin develop

删除本地feature分支：

git branch -d yourname

分支管理者

在该任务周期结束，所有人都merge到develop分支后，创建release分支，以'release-x.x'命名：

任意分支下git checkout -b release-0.1 develop

进行简单测试后，如果出现bug，在release分支下修改，提交：

git add filename
git commit -m "what have you changed"

将release分支合并到master分支：

git checkout master
git merge --no-ff release-0.1
git tag 0.1            # 对正式版本打tag

如果在release上修改过代码，还要合并到develop分支：

git checkout develop
git merge --no-ff release-0.1

将tag推送到远程，并将master更新：

git push --tags
git push

删除本地release分支：

git branch -d release-0.1

对git flow的简化和实践中的问题

采用git flow后的git network如图：

• 简化hotfix分支：hotfix分支用于在master出现bug后紧急修复。因为我们项目的迭代较快，用户较少，衡量新建hotfix分支的复杂程度，暂时删去。但在更大规模的项目中，hotfix很值得使用。

• git flow的优点：远程只有master和develop两个分支，且除版本管理者外他人无权修改master代码，保证出现问题时，进行修复工作的目的清晰。

• 对测试人员的不友好：理论上，release分支的作用包括了对即将发布版本的测试。但是可以发现，此处的release分支仅仅为本地分支，即版本管理者在将develop分支发布到master分支的过程中，测试人员是无法切换到release分支的。这一点对测试人员并不友好。但在我们的项目中，反而比较合适。由于项目属于课程设计，且不具有盈利性，要求测试人员在版本上线当晚必须投入到测试工作并不合理。通过衡量等待测试完成的时长和上线后出现bug的严重性，我们决定采用目前的分支管理方法，即在分支管理人员在release分支运行自动化测试工具进行功能测试后，发布到master分支。测试人员在之后的几天里，对项目新增代码进行代码级别的测试。

• 对开发结束后再次修改代码的不友好：可以发现，在结束自己本周期的开发任务，删除本地feature分支后，如果再次发现自己的修改存在bug，仍然需要重新拉取feature分支，这是一个比较繁琐的过程。我们也发现了存在部分成员在此时会直接进入develop分支修改代码。

• git branch和git status至关重要：提交错了分支和文件引发的版本回滚比较繁琐，因此提交前一定注意，要对自己的提交动作负责。