研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

07 | 分支管理:Facebook的策略,适合我的团队吗?

葛俊 2019-09-06
你好,我是葛俊。今天,我来跟你聊聊研发过程中的 Git 代码分支管理和发布策略。
在前面两篇文章中,我们讨论了持续开发、持续集成和持续部署的整个上线流程。这条流水线针对的是分支,因此代码的分支管理便是基础。能否找到适合自己团队的分支管理策略,就是决定代码质量,以及发布顺畅的一个重要因素。
Facebook 有几千名开发人员同时工作在一个大代码仓,每天会有一两千个代码提交入仓 ,但仍能顺利地进行开发,并发布高质量的产品。平心而论,Facebook 的工程水平的确很高,与他们的分支管理息息相关。
所以在今天这篇文章中,我会先与你详细介绍 Facebook 的分支管理策略,以及背后的原因;然后,与你介绍其他的常见分支管理策略;最后,向你推荐如何选择适合自己的分支策略。

Facebook 的分支管理和发布策略

Facebook 的分支管理策略,是一种基于主干的开发方式,也叫作 Trunk-based。在这种方式中,用于开发的长期分支只有一个,而用于发布的分支可以有多个。
首先,我们先看看这个长期存在的开发分支。

开发分支

这个长期存在的开发分支,一般被叫作 trunk 或者 master。为方便讨论,我们统一称它为 master。也就是说,所有的开发人员基于 master 分支进行开发,提交也直接 push 到这个分支上。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 日拱一卒
    看完这篇后,最大的感受就是Git是个宝库,之前对它的使用还停留在表面,我要去找本书系统学习一下。

    作者回复: Git的却很强大,很方便。确实也需要投入时间学习。我2010年初始Git的时候,找一个Git老手讨教,他非常热心地给我讲了一个半小时,我还是迷迷糊糊。不过现在想起来还是很感激他 :)

    这个链接是一个有趣的图形化Git学习工具。你可以看看:http://git-school.github.io/visualizing-git/#cherry-pick

    2019-09-13
    6
  • 日拱一卒
    全栈是趋势,这是不可避免的。
    全栈不意味着所有事情都亲力亲为,从个人发展的角度来说,肯定还是需要先在某个方向上做专做精,然后对项目涉及的其他方面由浅入深的逐渐熟悉。在读圣贤书的同时,也要知窗外事。

    作者回复: 👍👍👍

    2019-09-13
    1
  • 旭东
    想问一下老师,Facebook的开关是配置系统统一管理的吧?那么多功能分支,都靠开关管理,如何做好多个配置开关有效快速管理?

    作者回复: 是统一管理的。这个系统叫GateKeeper。推荐你看看这个,有很多细节:https://www.quora.com/How-does-Facebooks-Gatekeeper-service-work

    2019-09-12
    2
    1
  • phobal
    像 Facebook 这种主干(master)开发模式,每个人的代码每天都会合入到 master,实际中经常会有这样的情况:A、B 两个 feature 同时在进行,但上线时间不同,A 先上,那基于这种模式,A 上的话就会带入 B 的代码,难道 A 上的时候再基于上一个稳定版本 tag 再 cheery-pick A 的所有功能代码到测试分支?

    作者回复: 如果B的功能还没有准备好给用户使用,可以使用功能开关隐藏。

    2019-09-07
    1
  • 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-06
    2
    1
  • tk
    有没有toB的分支模型建议,多客户,核心功能相同,但是多个客户可能有不同的功能集合或者定制

    作者回复: 会持续开发新的功能吗?如果可以的话,推荐一个分支,使用功能开关控制。如果不行,就只能使用多个发布分支。

    2019-11-20
  • Robin
    facebook 的 Trunk-based 模式感觉没有 code review 流程介入呀,开发者直接push到master就测试上线了吗?

    作者回复: 有Code Review呀,请参考第5篇文章以及第12,13篇。

    2019-11-15
  • 我来也
    学习了。

    以前就我一个人用git时,只能在官网(https://git-scm.com/book/zh/v2)看看文档。
    很多命令都不知道在什么场景下使用。
    之前看耗子书关于分支管理的文章,也是云里雾里,很多命令不知道为什么那么用。

    现在新工作环境中,由于需要跟别人协作,用的git命令也是越来越多了。
    现在再来看老师的这篇文章,就不再吃力了。

    我现在很喜欢git rebase 和 git cherry-pick。
    我也很努力的保持分支线性,看上去好看。😄
    之前很小的提交都是用git merge -no-ff来合并的。

    总之,这个东西是熟来生巧。

    作者回复: git 很好玩的!对提高个人效能很有用。

    2019-11-01
  • 无名路人
    老师,为什么用的是rebase而不是merge

    作者回复: 因为它可以确保线性的代码提交历史,从而容易定位问题。请参考本文中的"能够确保线性的代码提交历史"部分。

    2019-09-17
  • 高倩
    主干开发模式,对于开发的拆分能力要求很高,同时从测试的角度,又怎么确保整个项目和产品功能的完整性呢?

    作者回复: DevOps,测试左移,测试右移都是比较有效的办法。后面的文章,会有比较详细的介绍,敬请期待。

    2019-09-16
  • XUN
    老师能不能讲讲移动端的开发管理,看了几篇都是后端的集成和发布流程

    作者回复: 前边描述的各种原则,在移动端后端都是一致的,比如说持续开发,持续集成,持续交付等。

    就拿在iOS的Facebook APP 的开发做例子。首先他们也是采用单主干的开发分支模式。要求代码提交的原子性,以及master分支上代码的线性历史。在持续集成方面。他们也是使用的Phabricator作为历程和质量控制中心,进行各种各样的代码入库前检查。在持续交付方面。他们也是采用了和后端类似的方式,每隔一定时间进行一次全量的构建和验证。

    当然,也会有一些差别。我在后面的文章中会找机会详细描述。

    感谢你的提问!

    2019-09-07
  • 囧囧冰淇淋
    看到今天,感觉研发和代码越来越有趣了XD

    作者回复: 对大家有用,让大家觉研发有趣,感觉写文章越来越有趣了XD

    2019-09-07
  • 李双
    各种分支管理策略,学习!问下,基于base开发的这种方式,是不是根据时间线,截止某一时间点(或者某个版本号之前的),代码验证过了,就可以上线了,而不是根据业务功能的先后紧急!

    作者回复: 对的。这种方式是发布周期与功能解耦。版本火车一列一列发出去。功能开发者自己决定把commit搭乘哪一列。办不上的话,没办法,等下一列。

    2019-09-06
收起评论
13
返回
顶部