Open mambat opened 7 years ago
Git Flow 分支模型约定了 5 种分支，模型比较复杂。需要团队中每个人都能正确地理解和选择正确的分支进行工作，对整个团队的纪律性提出了很高的要求。
规则越复杂，应用起来就越难，导致很多团队不得不借助额外的 Git 扩展脚本 gitflow 去应用这一套复杂的规则。
Feature 分支有一下两个明显的好处：
同时 Feature 分支也带来如下两个问题：
Feature 分支在较长周期的开发完成后才能 merge 回 develop 分支，而在此期间 develop 分支可能已经被其他 Feature 分支修改过。
即使其他 Feature 分支进行过 rename 这种非常简单的重构，merge 时也需要处理大量的冲突。
Feature 分支降低了代码集成的频率，big bang conflict 总是无法避免。
原则上要求各 Feature 分支的负责人将代码 merge 回 develop 分支，发现冲突、即刻解决。但一旦持续集成时、发现代码运行状态异常，该由哪个 Feature 负责人去解决问题？
Feature 分支的问题归根结底是 代码隔离 和 持续集成 的矛盾。
代码隔离
持续集成
Hotfix、Release 甚至 Feature 分支都有可能需要自己的持续集成环境，这是需要额外的硬件资源和虚拟化能力的，对小团队都是个很大的挑战。
关于分支模型 Git Flow 的思考
复杂度
Git Flow 分支模型约定了 5 种分支，模型比较复杂。需要团队中每个人都能正确地理解和选择正确的分支进行工作，对整个团队的纪律性提出了很高的要求。
规则越复杂，应用起来就越难，导致很多团队不得不借助额外的 Git 扩展脚本 gitflow 去应用这一套复杂的规则。
Feature 分支
Feature 分支有一下两个明显的好处：
同时 Feature 分支也带来如下两个问题：
提高了 merge 的成本
Feature 分支在较长周期的开发完成后才能 merge 回 develop 分支，而在此期间 develop 分支可能已经被其他 Feature 分支修改过。
即使其他 Feature 分支进行过 rename 这种非常简单的重构，merge 时也需要处理大量的冲突。
持续集成
Feature 分支降低了代码集成的频率，big bang conflict 总是无法避免。
原则上要求各 Feature 分支的负责人将代码 merge 回 develop 分支，发现冲突、即刻解决。但一旦持续集成时、发现代码运行状态异常，该由哪个 Feature 负责人去解决问题？
Feature 分支的问题归根结底是
代码隔离和持续集成的矛盾。为每个分支提供持续集成环境是个挑战
Hotfix、Release 甚至 Feature 分支都有可能需要自己的持续集成环境，这是需要额外的硬件资源和虚拟化能力的，对小团队都是个很大的挑战。