译:关于 Git 提交,我知道的 89 件事

原文:https://www.jvt.me/posts/2024/07/12/things-know-commits/
作者:Jamie Tanna
译者:ChatGPT 4 Turbo

这篇文章在我脑海里盘旋了大约 5 周,它可能会成为一篇“活文档”,我会随着时间更新它。

以下是我在过去 12 年里关于 Git 提交和提交历史学到的一些事情,排名不分先后。这既包括在 2-12 人的团队中的公司经历,也包括在有广泛贡献者的开源代码库中的经历。

  1. Git 有不同的用途 – 协作工具、备份工具、文档工具
  2. Git 提交消息非常棒
  3. 我从未遇到过像我这样喜欢阅读提交消息的人
  4. 通过提交找出为什么会进行更改,比通过问题/错误跟踪器要容易
  5. 拥有一个写着 “各种修复。DEV-123” 的提交,比仅写着 “各种修复” 的提交要好
  6. 当问题本身没有有用信息时,拥有一个写着 “各种修复。DEV-123” 的提交反而更糟
  7. 我更喜欢使用 rebase-merge。然后是 squash-merge,最后是 merge (编者注:我是 squash-merge > rebase-merge > merge)
  8. 如果你不学会如何 rebase,你就错过了一个很好的技能
  9. 当事情出错时,那些说 “直接删除仓库” 的人真的让我很沮丧
  10. 学会如何使用 git reflog,它会帮你保存那些本可以恢复的仓库和工作
  11. 学会如何使用 git reflog,你将能够从并不那么糟糕的错误中拯救自己
  12. 学会再多的花哨工具和命令也不能防止你时不时地搞砸
  13. 我最近的一个 botched rebase 是在上周,我需要用 git reflog 来帮忙解决问题
  14. ==学会如何撤销强制推送,然后学会如何更安全地强制推送(记住 =ref !!)==
  15. Squashing 是对精心编写的原子提交的浪费
  16. Squashing 比 100 个垃圾提交要好
  17. Squashing 并在合并时编写一个好的提交消息是好的
  18. Squashing 后不重新编辑消息是最糟的
  19. 当你有 100 个垃圾提交,然后 Squashing 但不重新编辑消息时,这是一种罪
  20. Squashing 后不重新编辑消息,比来自包含 100 个垃圾提交的分支的合并提交更糟
  21. 编写一份详细的 PR/MR 描述但不用它来通知 squash-merge 消息是浪费时间
  22. 编写提交消息帮助我发现缺失的测试案例、缺失的文档,或无效的思考过程,因为它帮助我重写_为什么_进行更改
  23. 使用你的 git log 作为 standup 更新的指示是有效的
  24. 我不会特意去签名我的提交(除非我被迫)
  25. 如果我必须签名我的提交,使用 SSH 密钥签名让它几乎不那么糟糕
  26. 如果你在仓库间移动文件,你需要保持历史完整性,使用 git subtree
  27. 提交应该是原子的 – 所有代码、测试和配置更改都应该在里面
  28. 我花费相当一部分时间确保每个提交原子地通过 CI 检查
  29. 一些人做了可怕的事情,比如把他们的实现代码和测试代码分离
  30. 将文档放在单独的提交中是可以的 – 我们不必在一个提交中交付一个完整的端到端功能
  31. 使用 squash-merge 的仓库很糟糕
  32. 作为开源项目的维护者,我喜欢 squash-merge,这样我可以重写贡献者的提交消息
  33. 有时候不值得指导怎样写一个给定的提交消息
  34. 你周围的人影响你写提交的方式
  35. 预先做好功课,使你的历史原子化
  36. 事后将一个大提交分割成原子提交要痛苦得多
  37. 原子地分割工作对于改善你的奖励驱动很有好处 – 你可以完成更多事情
  38. 原子提交与 prefactoring 非常搭配
  39. 有时候,重构的提交可以分到不同的 PR 中(特别是如果使用了 squash-merge)
  40. 编写提交信息可能比实现需要更长的时间
  41. 提交信息的长度可能比提交中改动行数的数量级还要大
  42. 如果你在提交信息中写了很多“和”或者“也”,你可能尝试做了太多事情
  43. 在过去通过 Git 提交历史的翻阅帮助解锁了许多案例,我可以在没有原作者在场的情况下理解 为什么
  44. 提交信息是反思你所做的事情不仅仅是什么,更重要的是为什么的绝佳时刻
  45. 为什么比什么更重要 – 任何人都可以查看差异并大致弄明白做了哪些更改,但背后的意图是特别的调味料
  46. 如果你只写了发生了什么改变,那你很令人讨厌,我不喜欢你
  47. 解释了什么的提交比只有“修复”字样的提交更好
  48. Chris Beams 的文章,如何写一个 Git 提交信息 仍然是一篇出色的文章,距今将近 10 年了,这是一个很好的起点!
  49. 提交是提交者对假设和世界状态的时点解释。不要对他们太苛刻
  50. 我不想阅读你的更改的 AI/LLM 重写版本 – 要么自己写,要么就称之为 Various fixes
  51. 需要有一种方法可以添加注解(可能使用 git notes),来更正之前消息的假设
  52. 我不会一开始就写完美的提交信息 – 有时它们可能就像 rew! add support for SBOMssq,或者使用 git commit --fixup
  53. 通常,我会将非常好的原子性工作块分解为提交
  54. 有时我会将原子提交分解为多个提交
  55. 确保在你将代码更改发送给合作者审阅之前,你已经审查了自己的代码更改
  56. 审查你的提交信息应该和审查代码变更一样重要
  57. 让所有的贡献者对提交历史投入同样的关心是一场输仗
  58. 试图管理提交历史将会很痛苦
  59. 试图强制在代码审查中审核提交信息将会很痛苦
  60. 试图管理提交历史确实会导致对变更的文档和考虑水平的提高
  61. 使隐式假设显式化真的很有用
  62. 引入 commitlint 可能有用,但也可能令人沮丧
  63. 让你的合作者自愿写好提交信息总比强迫他们来得更好
  64. 有些人就是不写,这也没关系
  65. 写作是一种技能
  66. 我在写作(提交信息)上不是完美的
  67. 有时我懒得写完美的信息
  68. 有时我写了一些真正棒极了的提交信息,给自己留下了深刻印象
  69. 使用 你的 Git 提交信息的模板 是促使正确做事的一个好方法
  70. fixup 提交git rebase --autosquash 是我学到的最佳 Git 技巧之一
  71. 我重视在一个具有多样化视角、技能和工作方法的团队中工作
  72. 但我也真的很重视拥有一个编写原子提交和良好提交信息的团队
  73. 编写提交信息和撰写精炼的用户故事/票据一样有用
  74. git commit -m sq 可能是我运行最多的命令
  75. 使用 git add -pgit commit -p 对于原子提交非常重要
  76. 永远不要使用 git add -ugit add .
  77. 学习何时可以使用 git add -ugit add .
  78. 我真的需要研究像 Graphite、git-branchless 等工具,以及其他提供堆栈式 PR 设置的方法
  79. 结合使用 规范提交semantic-releasego-semantic-release 在希望自动化和频繁发布时可以产生巨大变化
  80. 常规提交 作为你提交的框架非常有用
  81. 对于有 ADHD 的人来说,使用 常规提交 可以减少思考的需要,让你更多地关注变更本身
  82. 使用 常规提交 可以帮助你弄清楚何时一个提交尝试做了太多事情
  83. 我通过写作来 思考,所以提交消息有助于理解 我为什么做这件事
  84. 撰写一个好的提交信息,可能比存储在别处的文档更好
  85. 撰写一个好的提交信息,可能比代码注释更好
  86. 给人们学习的空间
  87. 给人们失败的空间
  88. 记住你曾经也不那么出色
  89. 文档很酷。多做一些