研发效率破局之道
葛俊
前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 的实用技巧，提高开发效率。
为什么要强调代码提交的原子性呢？这是因为它有以下 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
Jxin1.很棒，历史提交操作这块以前没概念，一直都是手动来，导致增加很多提交，学习了，练习下应用到工作去。
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-history2019-10-21 1
二狗没用过 没看懂(╥╯^╰╥) 看来还得拿栗子实践一下作者回复: Git很好玩的 ：）
2019-10-21
收起评论