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

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

git rebase -i
git rebase --interactive
git commit --amend
git add -p
git reset HEAD^
git add -p
助力持续集成
方便定位问题
代码结构更清晰
团队的研发效能
可维护性
可读性
团队代码的模块化
可以拆分提交的情况
交换多个提交的先后顺序的其他办法
修改非当前提交
交换多个提交的先后顺序
修改当前提交
对当前提交进行拆分
用工作区改动的一部分产生提交
分布式代码仓管理系统
提供方便、灵活的提交、分支处理功能
好处
提升代码提交的原子性
分布式代码仓管理系统
代码仓管理系统
思考题
5种基础操作
Git支持原子性的原因
代码提交的原子性
Git
玩转Git:五种提高代码提交原子性的基本操作

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

你好,我是葛俊。今天,我们来聊一聊 Git 吧。
毫无疑问,Git 是当前最流行的代码仓管理系统,可以说是开发者的必备技能。它非常强大,使用得当的话可以大幅助力个人效能的提升。一个最直接的应用就是,可以帮助我们提升代码提交的原子性。如果一个团队的成员都能熟练使用 Git 的话,可以大大提高团队代码的模块化、可读性、可维护性,从而提高团队的研发效能。但可惜的是,现实情况中,由于 Git 比较复杂,用得好的人并不多。
所以接下来,我会通过两篇文章,与你详细讲述如何使用 Git 助力实现代码原子性。今天这篇文章,我先与你分享 Git 支持原子性的 5 种基础操作;下一篇文章,则会给你介绍 Facebook 开发人员是怎样具体应用这些基础操作去实现代码原子性的。
通过这两篇文章,我希望你能够:
了解在分布式代码仓管理系统中,如何通过对代码提交的灵活处理,实现提交的原子性;
帮你学习到 Git 的实用技巧,提高开发效率。
我在第 21 篇文章中提到,代码提交的原子性指的是,一个提交包含一个不可分割的特性、修复或者优化。如果用一个提交完成一个功能,这个提交还是会比较大的话,我们需要把这个功能再拆分为子功能。
为什么要强调代码提交的原子性呢?这是因为它有以下 3 大好处:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文详细介绍了Git支持原子性的5种基础操作,旨在帮助开发者提高代码提交的原子性,从而提升团队的研发效能。作者首先强调了代码提交的原子性对团队协作的重要性,然后通过实际代码示例演示了如何使用git add -p命令将工作区中的代码拆分成多个提交,并介绍了对当前提交进行拆分的方法。另外,还介绍了修改当前提交和交换多个提交的先后顺序的操作方法。通过这些基本操作,读者可以更灵活地对代码提交进行修改、拆分、合并和交换顺序,为使用Git实现代码原子性的工作流打好基础。文章内容深入浅出,适合想要提高代码提交原子性的开发者阅读。文章还提到了一些思考题,引发读者思考和讨论。整体而言,本文对Git支持代码提交原子性的基本操作进行了全面而实用的介绍,对于想要提升团队研发效能的开发者具有重要参考价值。

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

全部留言(10)

  • 最新
  • 精选
  • 我来也
    git rebase -i 确实很好很强大,哈哈! 课后思考题 1.git cherry-pick 应该可以间接实现 2.git push -f / git rebase 已提交的代码后再git push -f 是危险操作。 人少时,吼一嗓子,再使用。人多时还是放弃吧。哈哈! 可是我经常这么干。🤦‍♂️ git push -f 后,轻则已拉取代码回本地的人需要手动修复下环境,重则之后推送的分支会被丢失。 (别人以为已经提交了,哪知还有人敢强推代码) 如果时间久了,别人本地分支也没留记录,可能代码就需要手敲了。(概率很小,但也可找回历史提交)

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

    2019-10-23
    3
    8
  • 雷霹雳的爸爸
    思考题留言区有同学已经答得很帅了,想了下就是做不到答得更好,只对第二个问题大概做一下补充,其实这个本体本质上还是git rebase和远端库共享的潜在冲突的问题,所以从这一点上讲,远端是fork的私库,任何共享都是基于TBD的CI基础上完成就非常重要了,对发布出去的东西,还是得注意品质,后悔药在git世界里不是没有,只是可能会让大家都很痛苦,发出去的东西就当泼出去的水,一路向前,不要回头 其实进来这里就是纯赞的,我本来以为我经常PR之前用git rebase -i仔细梳理就算是会了git了,但是看第一个场景git add -p我就直接跪了,也许以前见过,但是真没印象,一点也没有,我甚至没想过还可以这么干,虽然我不太认同这么部分的管理更新吧,要做这种部分提交,我觉得很大程度上是设计上没太想好,自己本地库这里还在debug的感觉;但是git的强大真的可见一斑

    作者回复: git add -p 我个人还是常用的。因为在写代码的时候,常常会看到一些小的地方需要修改,就顺手改了。但是在产生提交的时候又不合适放到一个提交里,所以用git add -p 去分开。 另外TUI的git工具tig有一个命令`1`可以非常方便地进行git add -p的操作,可以一行一行的进行挑选。所以拆分也很方便。

    2020-01-16
    2
    5
  • 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
    3
    2
  • 许童童
    思考题 可以通过强制push: git push -f 覆盖掉在远程的分支,不过这样做确实很危险。

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

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

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

    2019-10-21
  • 一打七
    老师操作四说交换AB后,重新有选择地放到 origin/master 上面。但结果是放到master,并不是origin/master,是不是表述的不够严谨?
    2023-10-31归属地:北京
  • BBQ
    老师,不知道是不是我的理解有问题 >同时,在没有接–hard 或者–soft 参数时,git reset 会把目标提交的内容同时复制到暂存区,但不会复制到工作区。 我看了您的控制台输出 ,我自己也试了一下,reset 之后,之前Commit 的修改会全部复制到工作区,不是复制到暂存区,reset 之后暂存区并没有内容。 多谢!
    2021-05-08
  • 巫山老妖
    git rebase的操作,我们大多是在合并分支的时候用到,用于原子性提交确实日常没怎么用,因为要让大部人做到原子性提交还是件不容易的事情
    2021-04-16
  • 送普选
    简单用过git,有个问题,若只提交到本地分支,不推送到远程分支,若本地电脑硬盘故障代码就丢失了,每日多次推送会减少损失,但从远程还是没有最近没推送的代码。请问葛老师我理解对吗?这种情况如何解决?谢谢!
    2021-02-09
    2
  • scguo
    给推荐一个git的学习工具,https://github.com/Gazler/githug
    2020-12-21
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部