07 | 分支管理：Facebook的策略，适合我的团队吗？
该思维导图由 AI 生成，仅供参考
Facebook 的分支管理和发布策略
开发分支
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Facebook采用的Trunk-based分支管理策略强调主干开发，禁止功能分支存在。代码合并采用rebase而非merge，发布分支从master拉出，进行测试、稳定，发现问题后在master上修复，然后cherry-pick到发布分支上。部署包括每周一次的全量代码部署、每天两次的日部署，以及每天不定次数的热修复部署。这种简单明了的分支管理和部署流程适合需要高质量产品发布的团队。Facebook的主干开发模式能促进频繁的代码集成检验，确保线性的代码提交历史，为流程自动化提供便利。除了主干开发，还介绍了Git-flow工作流、Fork-merge和灵活的功能分支组合成发布分支等分支管理方式。总结来说，尽量减少长期分支的数量，代码尽早合并回主仓，方便使用CI/CD等方法保证主仓代码提交的质量，是选择分支策略的基本出发点。 Facebook的单主干开发分支强迫代码进行原子化，确保每一个提交都尽快合入master，并保证代码质量。这种方法对功能模块化、代码稳定性和开发者日常工作都有帮助。一个流程设计、实施得好，对产品来说可以提高质量，对团队来说可以提高效能，对个人来说可以帮助成长。 Facebook的主干开发模式适合需要高质量产品发布的团队，而选择分支策略时应尽量减少长期分支的数量，代码尽早合并回主仓，以确保主仓代码提交的质量。
《研发效率破局之道》，新⼈⾸单¥59
全部留言(24)
- 最新
- 精选
技术修行者
看完这篇后，最大的感受就是Git是个宝库，之前对它的使用还停留在表面，我要去找本书系统学习一下。作者回复: Git的却很强大，很方便。确实也需要投入时间学习。我2010年初始Git的时候，找一个Git老手讨教，他非常热心地给我讲了一个半小时，我还是迷迷糊糊。不过现在想起来还是很感激他 ：） 这个链接是一个有趣的图形化Git学习工具。你可以看看：http://git-school.github.io/visualizing-git/#cherry-pick
2019-09-13215
旭东(Frank)想问一下老师，Facebook的开关是配置系统统一管理的吧？那么多功能分支，都靠开关管理，如何做好多个配置开关有效快速管理？作者回复: 是统一管理的。这个系统叫GateKeeper。推荐你看看这个，有很多细节：https://www.quora.com/How-does-Facebooks-Gatekeeper-service-work
2019-09-12310
phobal像 Facebook 这种主干（master）开发模式，每个人的代码每天都会合入到 master，实际中经常会有这样的情况：A、B 两个 feature 同时在进行，但上线时间不同，A 先上，那基于这种模式，A 上的话就会带入 B 的代码，难道 A 上的时候再基于上一个稳定版本 tag 再 cheery-pick A 的所有功能代码到测试分支？作者回复: 如果B的功能还没有准备好给用户使用，可以使用功能开关隐藏。
2019-09-076
Johnson听起来trunk-base这种方式基本和集中式的svn和perforce是一个思路，那疑问就是为啥不直接用perforce,收费？学习成本？需要额外的运维投入？ trunk-base针对pull request的方式还有一个疑问，怎么做pre checkin的code review来控制入库代码的质量？ 我能想到的好像还是集中式的那种checkin必须使用固定的工具，这个工具会去自动获取这个提交的code review，如果没有就不允许checkin.作者回复: > 听起来trunk-base这种方式基本和集中式的svn和perforce是一个思路，那疑问就是为啥不直接用perforce,收费？学习成本？需要额外的运维投入？ 非常好的问题。我觉得至少有以下几个好处： 1. 分布式的好处，使得开发人员在本地操作速度快。 2. 分布式的另一个好处。虽然我在文章中没有写，使用的频率也不是很高，但是开发人员的个人repo是可以互相推送代码进行合作的，不经过统一的中央repo。 3. Git开源。事实上，2015年左右，Facebook每天有太多的commits，所以Git的性能逐渐不能满足。于是Facebook尝试修改Git的代码。不过因为Git社区觉得Git代码仓不应该超级大，所以没有合作成功。最终Facebook从Git转向了Mercurial（hg）。ht是另一个类似Git的分布式代码仓管理系统。hg也是开源，Facebook通过提高hg解决的commits太多的问题。这就是使用开源的好处。这里强调一下，虽然Facebook从Git转到了hg，但是今天文章中讨论的分支策略对hg也是有效的。 4. Git免费 5. 在进行周部署，日部署、热修复部署中各种分支处理，Git的比svn，perforce强大。这一点因为我对Perfoce不是特别熟悉，不是100%确定。 > trunk-base针对pull request的方式还有一个疑问，怎么做pre checkin的code review来控制入库代码的质量？ 我能想到的好像还是集中式的那种checkin必须使用固定的工具，这个工具会去自动获取这个提交的code review，如果没有就不允许checkin. 这个的确是一种方式。比如使用Phabricator进行Code Review的时候，Phabricator对外提供接口。在开发者尝试push代码到Git Server的时候，Git Server可以会去Phabricator检查用户的commit有没有通过Code Review。 另外一个方式是让代码审查工具，比如Phabricator，Gerrit，在Code Review通过之后，代替开发者Push commit。
2019-09-0645
菜头facebook 的原子化提交这块，开发是以什么标准拆分，确保原子性的。老师能否帮忙介绍下。谢谢作者回复: 几个标准: 1. 提交不要超过一个功能。如果是bug fix的话可以有几个类似的fix放到一起（因为提交太小也不好）。 2. 如果功能较大，提交应该是一个功能的子功能 3. 这个提交需要能够入master库后不会break master。也就是说，该提交在入master之后，上可以从这个提交的位置发布一个产品。当然可能会有Bug，但是不能出现功能不能用的情况。要么功能实现完成，要么用户看不到。 另外大小上来说，并没有严格规定多少文件多少行。但是要让代码审查者审查起来不能太困难。
2019-12-273- 技术修行者全栈是趋势，这是不可避免的。 全栈不意味着所有事情都亲力亲为，从个人发展的角度来说，肯定还是需要先在某个方向上做专做精，然后对项目涉及的其他方面由浅入深的逐渐熟悉。在读圣贤书的同时，也要知窗外事。
作者回复: 👍👍👍
2019-09-133 - GeekJ从上面文章中获取，您的cherry-pick 策略都是在master上进行修复，然后cherry-pick 至周部署分支或热修复分支。 针对这个场景，我有以下几个问题 1. master分支每天有很多提交，其分支代码与周部署分支&热修复分支很大可能已经不一致了，如何保证cherry-pick质量？为什么不是从待发布分支 cherry-pick 至 master 分支呢？ 2. cherry-pick 操作是自动化，还是手动的？
作者回复: 1/ 保证cherry-pick质量保证有以下几条： 1. cherry-pick需要把依赖提交链一起cherry-pick。比如需要cherry-pick 提交A改动了文件f。A之前的提交B改动了f的相同部分。那么，B也要被遗弃cherry-pick。同时，B的依赖提交也要cherry-pick。 2. master上提交的原子性。这样可以保证上述的依赖提交可以相对安全的cherry-pick而不会产生未完成的功能暴露给用户 3. 自动化测试。 采用从master分支上cherry-pick的主要原因是确保master的健康。发布分支相对稳定，所以在上面直接修复的话，fix会错过很多最新的master上的相关修改，所以稳定性会差一些。而在master上先修复可以确保master随时可用，master更像source of truth，这是大量开发人员能够共主干的前提。 2/ cherry-pick 操作是自动化的。工具部门提供Web界面让开发人员输入commit ID，工具自动辨别其他需要cherry-pick的commit链。开发人员确认之后工具自动cherry-pick。
2020-02-0222 
李双各种分支管理策略，学习！问下，基于base开发的这种方式，是不是根据时间线，截止某一时间点（或者某个版本号之前的），代码验证过了，就可以上线了，而不是根据业务功能的先后紧急！作者回复: 对的。这种方式是发布周期与功能解耦。版本火车一列一列发出去。功能开发者自己决定把commit搭乘哪一列。办不上的话，没办法，等下一列。
2019-09-062
小齐rebase 的时候冲突为啥是 git add & git commit 而不是 git add & git rebase --continue作者回复: 你是对的。我当时写的应该是在解决`git cherry-pick` conflict时的操作。我联系编辑修正一下。谢谢你指出错误之处！
2020-09-151
我来也学习了。 以前就我一个人用git时，只能在官网（https://git-scm.com/book/zh/v2）看看文档。 很多命令都不知道在什么场景下使用。 之前看耗子书关于分支管理的文章，也是云里雾里，很多命令不知道为什么那么用。 现在新工作环境中，由于需要跟别人协作，用的git命令也是越来越多了。 现在再来看老师的这篇文章，就不再吃力了。 我现在很喜欢git rebase 和 git cherry-pick。 我也很努力的保持分支线性，看上去好看。😄 之前很小的提交都是用git merge -no-ff来合并的。 总之，这个东西是熟来生巧。作者回复: git 很好玩的！对提高个人效能很有用。
2019-11-011
