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

25 | 玩转Git:五种提高代码提交原子性的基本操作

葛俊 2019-10-21
你好,我是葛俊。今天,我们来聊一聊 Git 吧。
毫无疑问,Git 是当前最流行的代码仓管理系统,可以说是开发者的必备技能。它非常强大,使用得当的话可以大幅助力个人效能的提升。一个最直接的应用就是,可以帮助我们提升代码提交的原子性。如果一个团队的成员都能熟练使用 Git 的话,可以大大提高团队代码的模块化、可读性、可维护性,从而提高团队的研发效能。但可惜的是,现实情况中,由于 Git 比较复杂,用得好的人并不多。
所以接下来,我会通过两篇文章,与你详细讲述如何使用 Git 助力实现代码原子性。今天这篇文章,我先与你分享 Git 支持原子性的 5 种基础操作;下一篇文章,则会给你介绍 Facebook 开发人员是怎样具体应用这些基础操作去实现代码原子性的。
通过这两篇文章,我希望你能够:
了解在分布式代码仓管理系统中,如何通过对代码提交的灵活处理,实现提交的原子性;
帮你学习到 Git 的实用技巧,提高开发效率。
我在第 21 篇文章中提到,代码提交的原子性指的是,一个提交包含一个不可分割的特性、修复或者优化。如果用一个提交完成一个功能,这个提交还是会比较大的话,我们需要把这个功能再拆分为子功能。
为什么要强调代码提交的原子性呢?这是因为它有以下 3 大好处:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • 我来也
    git rebase -i 确实很好很强大,哈哈!

    课后思考题
    1.git cherry-pick 应该可以间接实现
    2.git push -f / git rebase 已提交的代码后再git push -f 是危险操作。
    人少时,吼一嗓子,再使用。人多时还是放弃吧。哈哈!
    可是我经常这么干。🤦‍♂️

    git push -f 后,轻则已拉取代码回本地的人需要手动修复下环境,重则之后推送的分支会被丢失。
    (别人以为已经提交了,哪知还有人敢强推代码)
    如果时间久了,别人本地分支也没留记录,可能代码就需要手敲了。(概率很小,但也可找回历史提交)

    作者回复: 看来@我来也 是git的高手呀!分析得非常到位。👍👍👍

    2019-10-23
    2
  • 许童童
    思考题
    可以通过强制push: git push -f 覆盖掉在远程的分支,不过这样做确实很危险。

    作者回复: 是的。可以在本地修改git历史,然后git push -f推送到远端共享分支。
    再追问一步,这样做的危险性是什么呢?

    2019-10-22
  • Jxin
    1.很棒,历史提交操作这块以前没概念,一直都是手动来,导致增加很多提交,学习了,练习下应用到工作去。
    2.现在工作主要用idea,用git的拉推提交回滚啥的简单操作都是直接在idea上。涉及到拆分提交这类操作就要切命令行敲git 指令。感觉操作不连贯。老师工作中是纯命令的吗?这些操作跟idea是否有对应?如果有应该怎么做?
    3.git-history,小工具,但看历史变更更直观,推荐使用。

    作者回复: 我大部分的Git操作是在命令行中。主要使用原生的Git命令,以及tig,还有gitin。在VSCode中使用Git Graph插件做一些读历史提交的工作。

    IDEA我最近没有高频使用。以前使用的时候也没有大量使用它的GUI的Git部分。

    git-history,你指的是这个吗?
    https://github.com/pomber/git-history

    2019-10-21
    1
  • 二狗
    没用过 没看懂(╥╯^╰╥) 看来还得拿栗子实践一下

    作者回复: Git很好玩的 :)

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