Git协作工作流.md 6.1 KB
Git工作流
前言
目前的 Git 协作工作流的模式非常多，我们主要是借鉴主流的 Gitflow 进而构建我们的协作方式。
无论协作的方式再多，作为一个团队协作开发而言，协作必须有一个规范的工作流程。统一协作开发工作流，这样团队之间既可井然有序、高效地协作开发，同时项目开发迭代也会显得井井有序。
工作流
可知，每一个项目的一个端作为一个代码仓库，我们称之为项目单元。团队开发 与 维护主要是针对项目单元去开发、迭代甚至是维护，使用分支能够有效地避免不同开发工作之间的相关干扰。
一般而言，一个项目单元必须包括如下类型的分支:
长期存在分支 或 标签
master| 主分支
主分支属于线上部署的分支，是项目生产稳定运行的项目分支，该分支只能合并 发布分支 或 热修复分支。
test| 测试构建分支
测试构建分支 与 主分支是并行的，此分支基于运行于开发环境 与 测试环境。同时，从规范上面来说，尽量不要在测试构建分支上直接做开发，测试构建分支是由功能分支 或 修复分支合并而成。
publish| 发布分支
发行分支即是项目版本可以稳定发行的版本，此发行分支是基于主分支构建而来，主要用于记录版本的节点，必须基于 master 分支构建。
以上三个分支原则上不允许直接提交代码。
短期存在分支
feat| 功能分支
功能分支是由无指定版本的需求确立而成，针对无版本的需求 或 功能而建立一个功能分支，好处就是各个功能独立开发则不受影响，同时团队成员之间的协作隔离不容易产生冲突。
hotfix| 修复分支
修复分支亦称为补丁分支，假设生产分支出现异常等 bug 危急的情况，需要建议一个修复分支，使得主分支合并进而解决 bug，注意、修复分支在主分支合并的同时必须由开发分支也合并，同时发行版也要合并构建成小版本的发行版，测试通过后题需要基于热修复分支打标签。
更多细节结合 分支命名规范 部分阅读。
规范习惯
高频率、细粒度地提交
把大功能的实现尽可能分解成更多的相对独立的小模块，每个小模块测试完成后提交修改，再开始下一模块的开发。这样做能保证每次提交的内容高度相关，方便定位错误、解决合并冲突。
提交之前务必通过自测与单元测试
每次提交代码不要自以为然，必须要将改动的代码进行自测 或者 单元测试，确保开发环境 与 测试环境平稳正常运行，否则会造成持续集成不通过、程序运行失败，甚至影响团队成员之间相互开发协作。
周期性持续提交
经常提交势必让你每次提交的东西都很少，也有助于你只提交相关的改动。并且，你还能更频繁地与别人共享代码。通过这种方式，所有人在集成代码时都会感觉更轻松，也就能避免一些不必要的冲突。相比之下，如果每次提交的东西很多、改动很大、时间间隔很长，那么在代码合并过程中产生的冲突就很难解决了。约定: 在有改动的情况下，至少一天一提交。
分支合并
- 发布分支合并
发布分支合并必须经过测试组测试，验收通过后才能合并。一般来说是每次迭代上线前一步合并。
- 开发分支合并
开发分支合并功能分支，尽量做到"频繁合并"，也就是说尽量将功能需求分解成 N 个功能模块，每一个功能模块完成就提交代码并合并到开发分支，这样可以减少分支合并造成的冲突。
- 主分支合并
一般是上线后没出现问题需要回滚，就可以把发布分支 publish 合并到主分支 master，保持主分支的代码同步线上最新的。该操作一般是上线后的次日进行。
禁止直接在 master/publish/test 等合并、发布分支直接提交代码
示例
现在已经有了版本 1.0.0 发布版本 ，现在有新的版本规划 1.1.0
那么需要给予发布 1.1.0 新建一个版本开发分支。根据分支命名规范，我们定义为 v1.1.0。
# 基于 master
git checkout master
# 新建分支
git checkout -b v1.1.0
# 推送远端分支并跟踪
git push -u origin v1.1.0
开发完毕，先在本地自测通过，通过后合并功能分支到测试发布分支
切记千万不要在 test/publish/master 分支直接提交代码， test 分支是合并分支
# 推送代码前切记要先 pull 代码
git pull
# 如果有冲突，需要处理冲突再提交
# 没有冲突，可以合并到 test 分支构建测试
git checkout test
git merge v1.1.0
git push origin test
测试分支构建完成后，再进行一次自测
所有功能模块完成后，并通过测试验收后，代码可以上线，可以合并到 publish 分支
git checkout publish
git pull
git merge v1.1.0
git push
上线完成后，如果没有回滚问题，需要将 publish 分支合并到 master 分支上。
线上发现缺陷后仓库操作
基于版本标签新建热修复分支，格式为
{版本标签}_hotfix，如果没有跟踪版本，就使用hotfix分支。修复分支同样需要经过自测和测试验收，通过后合并入发布分支上线。
修复的提交需要写清楚修复的问题和内容。
资料
Git 是一个很好用的工具，熟练掌握 Git 是一个优秀工程师的基本功。
无论是习惯敲命令行还是喜欢用 GUI 工具，都要熟悉 Git 的基本原理、设计思想以及常用命令。
推荐一些学习资料：