了解基本流程之后，下面通过项目示例演示一下团队 GitLab Workflow 的工作流如何使用。假设有一个项目，已经创建了一个中央仓库，准备开发。
1. 创建开发分支（功能分支）
需求评审通过后，开发A和开发B准备开发新功能，开发A负责开发版本号为 V1.0.0 的需求，开发B负责开发活动需求，比如邀请有奖活动。
在这个示例中，开发A和开发B都需要为各自的功能创建相应的分支，新分支必须基于master分支拉取。那如何开新分支呢？有两种办法，第一种是在远程仓库中新建分支，然后同步到本地仓库；第二种办法是先在本地创建分支，再提交到远程仓库。
2. 开发完成，提交测试
开发A和开发B同时开发中，他们用老套路添加提交到各自功能分支上：
暂存：git add .
提交：git commit -m "提交备注"
拉取远程代码：git pull --rebase（带—rebase参数发生冲突时会有提示）
提交到远程仓库：git push
经过多次提交后，开发A在功能分支 feature_v1.0.0 经过自测后觉得OK了，这时他将功能分支 feature_v1.0.0 合并到 test 分支，并通知了测试C进行功能测试。
测试C在测试功能的过程中发现问题，提bug，开发A在 feature_v1.0.0 功能分支上做修复，修复完成后再合并到 test 分支。
3. 冲突处理
恰好此时，开发B也把他负责的邀请有奖功能完成了，把他的 feature_invite 功能分支合并到 test 分支，但合并的时候发生了代码冲突。常见代码冲突场景有三种：新增，修改，删除；发生代码冲突，必须告知相应的开发人员。
少量文件冲突：通过对比冲突文件的历史提交，保留开发A的代码，合并本地代码，如有不清楚/不懂，必须要与开发A沟通一起解决。
多文件冲突，比如几十个文件冲突。这种场景的发生可能有两种：
第一种是在开发之前没有规划需求影响的范围，在开发过程中没有与同事沟通，总结就是各干各的，合并的时候可能会出现很多文件冲突。
第二种大多是因为开发违规操作，比如功能分支合并了 test / demo分支，或者在不清楚影响范围的情况下，使用了rebase操作，强推push操作。
无论哪种情况，多文件冲突必须上报，由负责人处理。
幸好，开发B是个懂事的开发，同时系统的模块划分也处理得很好，只有 index.ts 文件冲突了。他先是告知了开发A代码文件 index.ts 冲突了，然后在本地的 test 分支对比了历史提交后，解决冲突，再次提交，并通知开发A检查冲突文件。没问题后通知测试D进行功能测试。
4. 功能测试完成，提交验收
开发A经过反复修 bug 后，终于可以让产品验收了。此时他把功能分支 feature_v1.0.0 合并到 demo 分支，并通知测试C，交付给产品E验收。
产品在验收过程中发现实现的功能有分歧或者有其他问题，提bug，开发A在 feature_v1.0.0 功能分支上做修复，修复完成后分别合并到 test 分支，demo 分支。
但别忘了，开发B此时也在同步开发，此时有两种情况：
- 开发B仍然处于功能测试阶段，禁止把代码提交到 demo 分支，这种情况不用处理。
- 开发B也通过了功能测试，需要提交到 demo 分支給产品F验收，当开发B将 feature_invite 功能分支合并到 demo 分支时，依然会发生和合并 test 分支时一样的冲突，处理冲突参考第三点。
5. 发版
版本号为 V1.0.0 的需求，测试和产品都验收通过后，准备发版。
开发A将功能分支 feature_v1.0.0 发起一个合并请求到master，由负责人审核代码（Code Review），评估代码影响范围，如有问题打回修改，没有问题后合并代码。
成功发版后，开发A打tag，开发A需要将master分支的代码分别同步合并到所有的功能分支，在此次示例中，需要合并到 feature_invite 功能分支。
6. 线上发现 bug
这里也是分两种情况，一种是简单修复，可以直接拉 hotfix 分支修复处理；另一种是重大bug（功能性bug），必须要经过测试验证，此时不能拉 hotfix 分支修复，而是重新开功能分支进行开发修复，验收通过后再次发版，牢记要打tag，便于回溯版本，定位错误。
hotfix 分支的处理：开发A从 master 分支上拉出了一个 hotfix 分支，提交修改解决问题，然后发起一个合并请求到 master 分支，负责人同意合并后，开发A同步到其他功能分支。
至此，一个项目协作提交流程的常规场景已经罗列完成，如果有其他场景需要处理，欢迎提问，也欢迎在评论区提出更好的解决方案。
若有收获，就点个赞吧
0 人点赞
