研发效率破局之道
葛俊
前 Facebook 内部工具团队 Tech Lead
34093 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 40 讲
开篇词 (1讲)
研发效率破局之道
15
15
1.0x
00:00/00:00
登录|注册

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

阶段4:继续开发D1
阶段3:推送提交C1到远端代码仓共享分支
阶段2:开发需求D
阶段1:开发需求C
多分支工作流具体步骤
阶段6:B1检查通过,推送到远程代码仓共享分支
阶段5:继续开发A1,并发出代码审查
阶段4:继续开发B2,同时得到B1的反馈,修改B1
阶段3:拆分需求B的代码,把B1'提交检查系统
阶段2:开始开发需求B
阶段1:开始开发需求A
单分支工作流具体步骤
设置本地分支
思考题
小结
两种工作流的对比
用本地多分支实现多个需求的提交的原子性
工作流一:使用一个分支完成所有需求的开发
Facebook开发者最常用的两种Git工作流是什么?

该思维导图由 AI 生成,仅供参考

你好,我是葛俊。今天,我们继续来聊聊如何通过 Git 提高代码提交的原子性吧。
在上一篇文章中,我给你详细介绍了 Git 助力提高代码提交原子性的五条基础操作,今天我们再来看看 Facebook 的开发人员具体是如何使用这些操作来实现提交的原子性的。
为了帮助你更直观地理解、学习,在这篇文章里,我会与你详细描述工作场景,并列出具体命令。同时,我还把这些命令的输出也都放到了文章里,供你参考。所以,这篇文章会比较长、比较细。不过不要担心,这些内容都是日常工作中的自然流程,阅读起来也会比较顺畅。
在 Facebook,开发人员最常使用两种 Git 工作流:
使用一个分支,完成所有需求的开发;
使用多个分支,每个分支支持一个需求的开发。
两种工作流都利用 Git 的超强功能来提高代码原子性。这里的“需求”包括功能开发和缺陷修复,用大写字母 A、B、C 等表示;每个需求都可能包含有多个提交,每个提交用需求名 + 序号表示。比如,A 可能包含 A1、A2 两个提交,B 只包含 B1 这一个提交,而 C 包含 C1、C2、C3 三个提交。
需要强调的是,这两种工作流中的一个分支和多个分支,都是在开发者本地机器上的分支,不是远程代码仓中的功能分支。我在前面第 7 篇文章中提到过,Facebook 的主代码仓是不使用功能分支的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文详细介绍了Facebook开发者常用的两种Git工作流,以及如何利用Git的功能来提高代码提交的原子性。作者通过具体操作步骤和相关命令示例,展示了单一分支和多个分支两种工作流的实际应用。通过模拟真实开发场景,阐述了如何使用Git来实现提交的原子性。文章还介绍了在实际开发中可能遇到的冲突处理方法,并提供了解决冲突的具体步骤和命令示例。两种工作流各有利弊,但都能促进代码提交的原子性,提高个人及团队的研发效能。读者可以通过本文清晰地了解如何在实际开发中应用Git工作流,提高代码提交的原子性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《研发效率破局之道》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(6)

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

    作者回复: >第二种为主,然后在某个branch内部结合第一种的情况比较容易驾驭 的确是这样。第1种操作的确是要求比较高。而且如果有比较多的提交的话,rebase的overhead会比较大。所以单独的分支上不推荐,产生太多的提交。 > 很头疼的问题是很多老同事没有深入学习git的主动性和激情 如果他们能够意识到git的强大能够帮助自己提高研发效率的话,可能就会更愿意投入一些。能不能给他们搞点集体培训什么的?对团队效能提升帮助应该不错

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

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

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

    作者回复: http://onlywei.github.io/explain-git-with-d3/#rebase 交互式的界面学rebase。推荐看看 :)

    2019-10-23
    2
  • 我来也
    学习了,这两种方式我都会,也经常用。 我比较喜欢线性的提交历史,不喜欢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
    2
    2
  • 浇了汁鸡
    还有一种合并方式叫做'半线性历史记录',(https://stackoverflow.com/questions/59714347/semi-linear-merge),先把特性分支基于master做rebase,再merge --no-ff,既可以看到每次合并引入点,又能近似拥有线性历史的定位问题的便捷性
    2021-11-29
  • 巫山老妖
    第一种虽然能够不切换分支完成原子性提交,但感觉复杂性也变高了,要求所有人都能掌握还是比较困难,目前我们团队还是以第二种为主,不过有些同学还是习惯用merge来合并分支
    2021-04-18
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部