「译」我对 Git 提交的89个认识

Edited on Waline:

img

这篇文章已经在我脑海中酝酿了大约5周，可能会成为一个“活帖”，我会不断更新。

这是我在过去12年里，关于Git提交和提交历史的一些经验总结，顺序不分先后。这些经验来自于在公司中与2-12人团队的合作，以及在开源代码库中与各种贡献者的合作。

  1. Git有不同的用途——协作工具、备份工具、文档工具
  2. Git提交信息非常棒
  3. 我从未遇到过像我这样喜欢阅读提交信息的人
  4. 通过提交记录查找为什么做出某个更改，比通过问题/错误跟踪器更容易
  5. 一个包含“各种修复。DEV-123”的提交比一个仅包含“各种修复”的提交更好
  6. 一个包含“各种修复。DEV-123”但问题本身没有有用信息的提交更糟糕
  7. 我更喜欢rebase合并，然后是squash合并，再然后是merge
  8. 如果你不学习如何使用rebase，你会错过一个很好的技能
  9. 那些在事情出错时说“直接删除仓库”的人真的让我很沮丧
  10. 学习如何使用git reflog，它会帮你避免删除可恢复的仓库和工作
  11. 学习如何使用git reflog，你会发现可以从一些并不严重的错误中拯救自己
  12. 再多的花哨工具和命令的学习也无法避免偶尔犯错
  13. 我最近一次搞砸的rebase是在上周，我需要git reflog来帮我解决
  14. 学习如何撤销强制推送，然后学习如何更安全地强制推送（记住=ref！！）
  15. Squashing是对精心编写的原子提交的浪费
  16. Squashing比100个糟糕的提交要好
  17. 在合并时Squashing并写一个好的提交信息是好的
  18. Squashing后不重新编辑信息是最糟糕的
  19. Squashing时，如果有100个糟糕的提交而不重新编辑信息简直是犯罪
  20. Squashing后不重新编辑信息比从一个分支的100个糟糕提交中合并提交还要糟糕
  21. 写好PR/MR描述但不使用它来指导压缩合并信息是浪费时间
  22. 写提交信息帮助我发现了缺失的测试用例、缺失的文档或无效的思路，因为它帮助我重写了更改的原因
  23. 使用你的git log作为站会更新的依据是合理的
  24. 我懒得签署我的提交（除非被迫）
  25. 如果必须签署提交，SSH密钥签名让这件事几乎不那么糟糕
  26. 如果你在不同的仓库之间移动文件，你需要使用git subtree保持历史记录完整
  27. 提交应该是原子的——所有代码、测试和配置更改都应该在里面
  28. 我花了不少时间确保每个提交在CI检查中都是原子的
  29. 有些人做的事很糟糕，比如将实现代码和测试代码分开提交
  30. 将文档放在单独的提交中是可以的——我们不必在一个提交中交付整个端到端功能
  31. 使用压缩合并的仓库很糟糕
  32. 作为开源项目的维护者，我喜欢压缩合并，这样我可以重写贡献者的提交信息
  33. 有时教别人如何写提交信息并不值得
  34. 你周围的人会影响你写提交信息的方式
  35. 在前期做工作，使你的历史记录是原子的
  36. 事后将一个大提交拆分成原子提交更痛苦
  37. 原子提交对提高你的成就感有好处——你可以完成更多事情
  38. 原子提交非常适合预先重构
  39. 有时预重构提交可以进入单独的PR（特别是如果使用压缩合并）
  40. 写提交信息可能比实现花费更长时间
  41. 提交信息的长度可能是提交更改行数的十倍
  42. 如果你在提交信息中写了很多“和”或“也”，你可能在尝试做太多事情
  43. 过去通过查阅Git提交历史帮助我理解了很多没有原作者解答的原因
  44. 提交信息是反思你所做的事和为什么要做的一个很好的节点
  45. 为什么比什么更重要——任何人都可以通过diff大致看出做了什么更改，但背后的意图是特别的调料
  46. 如果你只写了什么更改，我会讨厌你
  47. 解释了什么的提交比只写了“修复”的提交要好
  48. Chris Beams的文章《如何写Git提交信息》 仍然是一篇优秀的文章，即使在近10年后，仍然是一个很好的起点！
  49. 提交是提交者的假设和世界状态的时间点解释。不要对他们太苛刻
  50. 我不想看你的AI/LLM重写的更改——要么自己写，要么叫“各种修复”
  51. 需要有一种方法可以添加注释（可能使用git notes）到以前的消息中以纠正假设
  52. 我不会一开始就写完美的提交信息——它们有时会像“重写！添加SBOM支持”或“sq”那样简短，或者使用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 -p和git commit -p对原子提交非常重要
  76. 永远不要使用git add -u或git add .
  77. 学会在何时可以使用git add -u或git add .
  78. 我真的需要研究像Graphite、git-branchless等工具，以提供一个堆叠的PR设置
  79. 使用conventional commits与semantic-release或go-semantic-release可以在想要自动化和频繁发布时产生巨大差异
  80. 使用conventional commits作为提交框架非常有用
  81. 对于有ADHD的人，使用conventional commits减少了思考的需要，有时可以让你更多地关注更改内容
  82. 使用conventional commits可以帮助你发现你是否在尝试在一个提交中做太多事情
  83. 我通过写作进行思考，因此提交信息帮助我理解为什么我做了这件事
  84. 写一个好的提交信息比写存储在其他地方的文档更好
  85. 写一个好的提交信息比写代码注释更好
  86. 给人们学习的空间
  87. 给人们失败的空间
  88. 记住你曾经也不那么出色
  89. 文档很棒,多做一些

来自：[1]:[https://www.jvt.me/posts/2024/07/12/things-know-commits/]