git解决冲突的四种方式_GIT工作流与团队管理

背景

GIT工作流是团队协作积累的代码治理经验。在敏捷开发中，选择合理的、灵活的、可靠的代码管理方式，可优化产研各阶段的在制品数量限制并提高协作效率，保障生产安全。

每个团队都会有一套自己代码管理流程，随着业务发展和项目规模变化，管理流程也需要不断适应改变。就像敏捷一样，是方法论而非生搬硬套。

工作流是什么样的？

• 集中式工作流

类似于集中式版本控制，以中央仓库作为项目所有修改的单点实体，在git中我们使用master分支作为主干分支，所有修改都提交到master上，在集中式工作流中我们只使用master。

集中式工作流

使用攻略

设定分支保护，防止冲突者强制覆盖

出现代码冲突，先将修改保存临时区再合并到工作区解决冲突，最后提交暂存区

• 功能分支工作流

功能分支工作流是为了解决开发过程中功能模块协作问题，不在master分支上做开发，每个功能模块基于一个专门的分支。功能开发促成了Pull Request 工作流，每个PR让技术负责人review代码，检查无误后merge到master分支上。

功能分支工作流

使用攻略

拉取远程仓库，基于master创建新分支feature并同步到远程，规定该功能分支是最小需求单元的协作分支，提测过程是将该分支Merge request到测试分支，发布线上也是将该分支合并至master。

• Git flow工作流

Git flow工作流是围绕项目发布的严格分支模型，用于管理大型项目，严格规范发布流程。

远程仓库作为开发者的交互中心，同时围绕master、release、develop、feature（feature是统称不止这一个）四种分支协作，完成多环境、多任务的代码管理。

Git flow工作流

使用攻略

feature功能分支是基于develop进行创建，在功能分支上进行一个周期的功能开发，多个功能并行开发就需要建立多个feature-XXXX分支

如果一个功能预备上线，需要先合并到develop分支上，并同时在此时develop上基础上建立一个release-XXXX分支

在此release分支上进行发布任务开发，比如bug修复，更新文档等，投产日合并release分支代码到master和develop，并且在master上对这次merge记录版本号，并打上tag。

总结：此工作流适合2C产品或者对发布产品进行严格控制的项目以及大型项目处理多需求并行开发，release分支进行预投产测试，develop进行开发测试。

• Fork工作流

开源项目二次开发，例如fix react框架缺陷支持业务开发，同时保持和社区未来版本一致。

• Github工作流

基于GitHub仓库开发，开源项目严格管理PR。

工作流能带来哪些好处？

工作流是帮助代码治理和生产控制的方法论，面向问题结合经典的工作流可以帮助我们积累自己的实践经验。

项目管理

• 任务并行

设计前置，任务池中同一项目各个模块可多人处理多个需求。整体迭代速度加快，要求代码可按敏捷细粒度任务独立进行发布。此时就需要引入功能分支开发流程。

任务并行

• 需求合并

多功能开发过程中，代码合并至主干会出现冲突。冲突是允许的，如果需求拆分不明确在代码层面有强耦合，导致代码风险。讨论其原因会很复杂，建议预先设计过程考虑，并合并有依赖需求，避免任务拆的太碎。如果客观原因无法合并，情况特殊可以采用临时版本独立验证、独立上线，一切需求都让路。

需求合并

• 风险评估

投产风险可能会存在多环境数据不一致问题，因此同一套代码也无法保证上线过程一定安全。故而测试阶段会对代码强约束，多环境不允许出现差异化代码。从敏捷角度来讲，小步快跑，高速迭代，势必会出现这样的差异化。不同项目需要合理判断风险，而不是一刀切。

团队协作

• 模块分工

前端模块分工可通过一个codebase多个文件夹，采用集中式工作流在一个主分支上协作开发。对于规模复杂度较高的项目，涉及跨工种且模块化开发，可通过git子项目关联，或者类似lerna分包分版本管理。

• 代码 Review

促成了PR工作流，代码库的生产代码统一管控，即可做到技术层面的代码审查。借助于gitlab的issue管理、代码批注功能，可以使版本代码可溯源，可沉淀知识库。

版本控制

• 集成版本树

版本控制需要从需求版本到部署应用版本建立统一的版本树。项目复杂度越高，不确定和不可控是需求推进的阻碍。建立集成版本树即可辅助团队协作亦可推动各模块自检梳理应用

• 生产安全控制

有了版本控制，不是一定杜绝了生产隐患。而是通过版本去锁定事故范围，快速定位问题。

总结

先有方法论，后有工作流。