这是一个旧的 issue，被我从 Hover 项目 issue 中移植过来，留档保存。
2018 年由 杨帆 提出
我们现在是什么样的分支策略 ？
我们现在基本上在『名义上』维护了两个比较关键的分支:
develop 分支
我们基本上是在 develop 进行开发，这个分支我们其实变换过多个名字，比如，feature/scenario; 之前我们的模式是，当我们决定在某个时间点的上线的时候，我们将某个分支 commit 到 develop 分支，并且拒绝或者期望其他人的 feature 不再 commit 到 develop 分支，来保证 develop 分支比较干净和简单;
master 分支
这个分支目的比较简单，当我们期望发布的时候，我们会从 develop 分支 merge 到 master 分支，打一个 tag 或者 release branch 同时，有需要 hotfix 的问题，我们会在这个分支上解决.
为什么我觉得这影响了我们开发的效率 ?
我觉得这样基本上导致我们是以 feature 为粒度进行开发和迭代; 因为其实这个 develop 分支就是一个 feature 分支，同时，大家在提测后，测试中，修复 bug 的阶段中, 都不期望有任何人来引入更多的变量或者变化的因素. 所以我们基本上是一个 feature 一个 feature 进行迭代开发的。 但是对于我们当前 iOS/Android 团队开发的规模，和人员的分布来说，其实我们总是有时间在同时开发多个 feature 的。 这其实意味着我们当前的迭代的模式已经不能满足我们当前的团队规模了。
我的想法是什么 ？
从分支模型上想，我想在 develop 和 master 分支之间添加一个 release 分支 变为
master 分支
还是那个作用，不变
release 分支
这个分支用来提测，和 bugfix; 假如以周为粒度的话，我们每周一提测一个版本. 然后基于这个版本 QA/QE 开始测试，测试的过程中会发现一些 bug， 然后，我们需要在这个分支上进行 bugfix; 同时把 bugfix cherrypick 到 develop 分支;
develop 分支
develop 分支是为了大家把下一步计划开发的内容统一到一个 iOS_Android 团队内部的分支上. QA_QE 并不测试这个分支, 我们基本上随时可以往这分支 push 东西; 但是从迭代的方式上想，我认为我们应该有固定的发布步骤，每周北京和杭州沟通好这周和下周上线的内容，把这周要上限的（不同人开发的） feature 都 merge 到 release 分支; QA/QE 集中在这个 release 分支上进行测试, 在遇到问题后，各个开发者跟进修复问题; 或者说，我想尽可能避免，因为测试一个 feature，导致另外的一些 feature 被 delay 的问题; 这样能够让更多的 feature 更快的发布给用户，集成到主线. 补充一下，其实这个就是 git-flow 的策略而已，但是和我们之前的选择不一样.
From GeorgeWu:
我觉得杨老师道出了 北京-杭州 合作开发模式的痛点，即多 feature 并行开发时，一些 feature 会被版本发布所 delay。杨老师的建议是：引入 release-* 分支，在这个分支上只做 bug fix，develop 分支开放合并，这样，并行开发的 feature 就可以更加自由的往 develop 合并，不会被版本发布所 block。我认为这一方案可能并不能解决想要解决的问题。以下是原因和建议。
为什么引入 Git-Flow 难以解决痛点
为简化描述我们假设发布周期固定为一周
开发周期长于发布周期
如果 feature 的开发周期普遍较短，那么每周开发的功能，在下一周初，基本所有的 feature 都会基本开发完成。这时拉出仅做 bug fix 的 release-* 是可行的。而如果 feature 的开发周期较长，尤其是大于发布周期时，每周一拉出的 release-* 也会有未完成的 feature，如此 release-* 将不得不做 bug fix 之外的事情 —— 完成未完成的功能。
release-* 分支的切出时机
release-* 分支的拉出时机面临两难选择：拉得早（比如周一），我们新 feature 上线永远会 lag 一周；拉得晚（比如周六），develop 分支就难以保持开放合并。我们保持 develop 开发合并事实的成本是，新 feature 延迟上线。
release-* 维护成本
首先需要维护额外的分支本身就存在成本。其次额外的分支会分散测试的精力，由于设想测试只测 release-* 分支，develop 上的 bug 也会延迟到下一周才被测试，如果开发者 pick-up 老代码需要额外精力的话，这里也会存在成本。
改进建议
根本的问题是：我们是希望 develop 更稳定（只有完成的 feature）还是更自由（随时合并开发过程中的 feature）。我们如果期望 develop 变得更自由，那么不可避免的我们需要放弃一些稳定性。release-* 分支的设想试图把稳定的因素集中在 release-* 分支上，从而释放 develop 的约束。事实上由于 release-* 与 develop 的密切关系（前者从后者基础上拉出），我们可能难以使前者的稳定性与后者的自由性共存。
我会更倾向于保持 develop 的稳定，从其他方面想办法让 feature 的集成变得更容易。
先预部署再集成
一些 feature 的集成难点可能在于，新 feature 的集成需要对 develop 本身做一些重构（refactor）。这样会引入新的风险，从而成为 block release 的因素而 delay。如果我们在新 feature 的开发过程中，先在 develop 上做好预部署（对 develop 做 refactor，使得后面的集成变得很方便），这一部分逻辑的改动会预先被测试 cover。Feature 开发完成后，集成也不会太困难。
先集成再开发
如果 feature 本身足够独立，我们事实上可以把开发中的 feature 先集成到 develop，但禁用这一功能。这样我们可以方便地决定在某次发布是否上线这一功能。
By 马家欣 on 2018-03-21T07:20:24 (imported from GitLab project)
From yangfan:
分支策略
发布分支 - master
当我们每次准备发布出去的时候，我们需要提交一次在发布分支中. CI 会 Track 发布分支, 当发布分支有更新的时候, CI 会按照发布配置重新编译, 并且发布到对应的平台如(App Store 和 Google Play).
测试分支 - release
当我们每次提测的时候, 我们会固定的提交到测试分支, CI 会 Track 测试分支, 按照测试的配置进行编译，发布到测试平台进行测试. 同时, 测试分支 也承担了修复 bug 的功能, 我们当在 QE 的测试的过程中，我们的 bug fix 应该在 release 分支上进行. 当发布后, 我们需要把 release 分支上所有的 bugfix, merge/checkpick 到开发分支上.
开发分支 - develop
developers 需要一个分支需要尽快的 merge 不同的 feature, 尽早的暴露问题, 同时有事一个分支我们能够测试的过程尽快的开发. 同时，开发分支的另外一个目的是，当测试分支仍然在测试的过程中的时候，开发者们仍然能够有一个比较稳定的分支在开发;
feature/* 分支
针对某一个比较大的 feature, 我们应该拉出来，进行开发，在这个 feature 开发的比较完整的时候，我们会再 merge 到 developer 的分支中去. 同时，能够为这个比较大的 feature 编译出来一个 App 能够更好的让产品提前得到反馈和试用，对所有以 feature/* 开头的分支，我们应该为其自动创建一个 CI 项目，并自动发不到测试平台，方便开发.
Workflow
对于工作流，我们可以参考这个链接： https://datasift.github.io/gitflow/IntroducingGitFlow.html 我暂时先不总结，先确定下来分支策略，然后再和大家沟通 Workflow 的事情。
By 马家欣 on 2018-03-21T07:20:30 (imported from GitLab project)