【技术博客】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相当重要：提交错了分支和文件引起的版本回滚比较繁琐，所以提交前必定注意，要对本身的提交动做负责。