开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第1天，点击查看活动详情
目前较为流行的工作流的抽象模型有Git Flow、Github Flow 与 Gitlab Flow等
在实际的开发的过程中进行了多种git工作流模式的尝试与探索，但直接套用模式并不能够满足当前的开发需求，所以做了相应的调整与变化。
这里只是根据自己的实际情况对分支管理进行简单介绍，大家也需要根据自己的实际情况进行调整。
🚩开发介绍
项目进入相对稳定的时期，便会进入迭代开发。整个开发流程也比较简单，开发完成后，分别在不同的环境测试通过后才能进行生产的发布。总结起来有以下特点：
迭代周期：1个月
环境：开发、测试、预演、生产
上线时间点确定：每月上线点固定不会改变
上线内容不确定：有紧急需求插队，上线时间随时调整
充分测试后才能上线：生产与开发测试环境相对隔离，所有内容需要进行所有测试环境后才能发不上线。
1️⃣分支管理
项目有多个环境，对每个环境分配了一个分支，这样每个分支测试相对独立互不干扰。每个特性会单独拉取不同的feature分支进行开发（生产问题也以feature分支的方式处理）。
2️⃣简单分支合并策略
在每个迭代中如果不产生任何异常情况，如：紧急需求，bug修复等。可以按照开发->测试->预演->生产的步骤逐层合并。
主要流程说明
开发人员从master分支拉去feature分支进行开发
开发完成并进行单元测试后提交合并请求将feature分支合并到dev分支，并进行集成测试
完成集成测试后提交合并请求将dev合并到test分支进行功能测试
功能测试完成后提交合并请求将test合并到master分支进行业务测试
验证完成后上线发布
3️⃣多需求并行开发
然而总不是这样有序的进行开发流程，有一些临时的需求加入进来，是的开发、测试并不是同事投产上线，所以使用多个特性分支进行分别开发分别合并。
主要流程说明
分别拉取不同的特性分支进行开发或者bug修复，如：feature/hotfix1和feature/hotfix2
开发完成并进行单元测试后提交合并请求将feature/hotfix分支合并到dev分支，并进行集成测试
完成集成测试后提交合并请求将feature/hotfix分支合并到test分支进行功能测试
功能测试完成后提交合并请求将需要上线的feature/hotfix分支合并到master分支进行业务测试
验证完成后上线发布
然而在实际进行的过程中发现，特性分支出现冲突时，会导致需要多次解决冲突的问题，这会产生较大的工作量与风险。所以为了规避这种多次解决冲突的情况，需要对冲突合并的策略进行调整。
4️⃣多需求并行开发一次解决冲突
整体流程并没有太大的区别，主要是需要区分先上线与后上线的特性分支。主要分为以下两种情况：
-
两个特性分支featureA和featureB有冲突，但是同时上线。那么可以将featureA和featureB合并成一个分支进行开发。
-
如果两个特性分支有先后上线的时间点且产生了冲突。如图所示，feature_before_conflict分支优先于feature_late_conflict分支上线，且两个分支产生冲突。则需要将先上线的分支合并到后上线的分支，再上到对应的开发、测试环境中。如图中每次提交测试需要将feature_before_conflict合并到feature_late_conflict分支然后再发布到测试环境。但最终上线生产，也就是合并到master分支时可以分开合并，从而规避了冲突多次解决的问题。
不足：feature_late_conflict和feature_late_conflict分支在测试的过程中不能有相互影响干扰的情况。
总结
- 同时上线的开发任务可以使用开发(dev)->测试(test)->预演(master)直接合并的方式。
- 不同时上线并行开发的任务可以使用多特性分支向不同环境合并的方式。
- 如果相互冲突的特性分支同时上线可以合并为一个特性分支进行开发。
- 如果相互冲突的特性分支不同时上线，可以将先上线的分支合并到后上线的分支，然后再合并到对应的测试分支。
