研发效率破局之道
葛俊
前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讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

26 | Facebook怎样实现代码提交的原子性?

葛俊 2019-10-23
你好,我是葛俊。今天,我们继续来聊聊如何通过 Git 提高代码提交的原子性吧。
在上一篇文章中,我给你详细介绍了 Git 助力提高代码提交原子性的五条基础操作,今天我们再来看看 Facebook 的开发人员具体是如何使用这些操作来实现提交的原子性的。
为了帮助你更直观地理解、学习,在这篇文章里,我会与你详细描述工作场景,并列出具体命令。同时,我还把这些命令的输出也都放到了文章里,供你参考。所以,这篇文章会比较长、比较细。不过不要担心,这些内容都是日常工作中的自然流程,阅读起来也会比较顺畅。
在 Facebook,开发人员最常使用两种 Git 工作流:
使用一个分支,完成所有需求的开发;
使用多个分支,每个分支支持一个需求的开发。
两种工作流都利用 Git 的超强功能来提高代码原子性。这里的“需求”包括功能开发和缺陷修复,用大写字母 A、B、C 等表示;每个需求都可能包含有多个提交,每个提交用需求名 + 序号表示。比如,A 可能包含 A1、A2 两个提交,B 只包含 B1 这一个提交,而 C 包含 C1、C2、C3 三个提交。
需要强调的是,这两种工作流中的一个分支和多个分支,都是在开发者本地机器上的分支,不是远程代码仓中的功能分支。我在前面第 7 篇文章中提到过,Facebook 的主代码仓是不使用功能分支的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • Geek_1988
    葛老师,请问提交代码的原子性,除了提高git技巧外,在工程上有什么需要注意的点吗?比如软件架构,设计模式。这方面应该随着语言和项目的不同会有较大的差异,有没有什么通用的原则?

    作者回复: 工程上,主要是解耦和增量开发。解耦好理解,把功能进行拆分。而增量开发这个一般大家提的不多。主要是在实现功能的时候,考虑怎么样实现最小子功能,即时这个子功能不能暴露给用户。我以后抽空详细写一下,通过代码的实际例子来解释应该更清楚。

    2019-11-03
  • Weining Cao
    从来不用rebase, 一直用merge,看来要好好学习下rebase了

    作者回复: http://onlywei.github.io/explain-git-with-d3/#rebase

    交互式的界面学rebase。推荐看看 :)

    2019-10-23
  • 我来也
    学习了,这两种方式我都会,也经常用。
    我比较喜欢线性的提交历史,不喜欢merge。

    但有个比较纠结的是。
    比如采用第二种方式:
    单独开发某个功能,也是采用小步走的方式,这样一个功能分支开发完后,可能有很多小的commit。
    如果这些commit都线性的推到远程,感觉也不好。
    目前只能先自己用rebase合并一些分支,然后再推。

    如果是使用git merge —no-ff的方式,这些小commit就可以保留,在历史中可以看到完整的开发过程。
    但是这样分支看上去就临时分叉了。
    不知道老师推荐用哪种方法。

    课后思考题一
    我能想到的笨办法:
    1。先备份当前分支,比如git branch temp
    2。git reset —hard HEAD^
    3。修改并git commit —amend —no-edit
    4。git cherry-pick 后面的commit 😄
    或者git checkout temp ;git rebase xxx 刚才修改后的commit (不知道可不可行)

    作者回复: 1-----
    > 但有个比较纠结的是...
    我一般是使用为rebase或者cherry-pick,把这些分支上的都放到合并到一个分支上,不使用merge --no-ff命令。

    至于提交的粒度,就要考虑原子性了。尽量是单个提交只完成单个需求。当然,有些时候如果bug fix很小,也可以选择把多个bug fix合并成一个提交。

    2-----
    > 1。先备份当前分支,比如git branch temp
    > 2。git reset —hard HEAD^
    > 3。修改并git commit —amend —no-edit
    > 4。git cherry-pick 后面的commit 😄
    > 或者git checkout temp ;git rebase xxx 刚才修改后的commit (不知道可不可行)

    这两种办法都可以,都很好!

    还有第三个办法,我一般是把提交交换顺序,把要修改的提交放到HEAD处修改。

    另外,我还第一次见到--no-edit。我以前都是用 commit --amend -a -C HEAD来完成类似功能 :)

    2019-10-23
  • Johnson
    第一种太烧脑了,对开发人员的git技能要求太高了,大部分的开发人员都不能正确驾驭,感觉工作中更多的是以第二种为主,然后在某个branch内部结合第一种的情况比较容易驾驭。很头疼的问题是很多老同事没有深入学习git的主动性和激情,稍微复杂点儿的操作就让别人帮忙操作。

    作者回复: >第二种为主,然后在某个branch内部结合第一种的情况比较容易驾驭

    的确是这样。第1种操作的确是要求比较高。而且如果有比较多的提交的话,rebase的overhead会比较大。所以单独的分支上不推荐,产生太多的提交。

    > 很头疼的问题是很多老同事没有深入学习git的主动性和激情
    如果他们能够意识到git的强大能够帮助自己提高研发效率的话,可能就会更愿意投入一些。能不能给他们搞点集体培训什么的?对团队效能提升帮助应该不错

    2019-10-23
    1
收起评论
4
返回
顶部