原文：https://www.jvt.me/posts/2024/07/12/things-know-commits/
作者：Jamie Tanna
译者：ChatGPT 4 Turbo
这篇文章在我脑海里盘旋了大约 5 周，它可能会成为一篇“活文档”，我会随着时间更新它。
以下是我在过去 12 年里关于 Git 提交和提交历史学到的一些事情，排名不分先后。这既包括在 2-12 人的团队中的公司经历，也包括在有广泛贡献者的开源代码库中的经历。
- Git 有不同的用途 – 协作工具、备份工具、文档工具
- Git 提交消息非常棒
- 我从未遇到过像我这样喜欢阅读提交消息的人
- 通过提交找出为什么会进行更改，比通过问题/错误跟踪器要容易
- 拥有一个写着 “各种修复。DEV-123” 的提交，比仅写着 “各种修复” 的提交要好
- 当问题本身没有有用信息时，拥有一个写着 “各种修复。DEV-123” 的提交反而更糟
- 我更喜欢使用 rebase-merge。然后是 squash-merge，最后是 merge （编者注：我是 squash-merge > rebase-merge > merge）
- 如果你不学会如何 rebase，你就错过了一个很好的技能
- 当事情出错时，那些说 “直接删除仓库” 的人真的让我很沮丧
- 学会如何使用
git reflog，它会帮你保存那些本可以恢复的仓库和工作 - 学会如何使用
git reflog，你将能够从并不那么糟糕的错误中拯救自己 - 学会再多的花哨工具和命令也不能防止你时不时地搞砸
- 我最近的一个 botched rebase 是在上周，我需要用
git reflog来帮忙解决问题 - ==学会如何撤销强制推送，然后学会如何更安全地强制推送（记住 =ref !!）==
- Squashing 是对精心编写的原子提交的浪费
- Squashing 比 100 个垃圾提交要好
- Squashing 并在合并时编写一个好的提交消息是好的
- Squashing 后不重新编辑消息是最糟的
- 当你有 100 个垃圾提交，然后 Squashing 但不重新编辑消息时，这是一种罪
- Squashing 后不重新编辑消息，比来自包含 100 个垃圾提交的分支的合并提交更糟
- 编写一份详细的 PR/MR 描述但不用它来通知 squash-merge 消息是浪费时间
- 编写提交消息帮助我发现缺失的测试案例、缺失的文档，或无效的思考过程，因为它帮助我重写_为什么_进行更改
- 使用你的
git log作为 standup 更新的指示是有效的 - 我不会特意去签名我的提交（除非我被迫）
- 如果我必须签名我的提交，使用 SSH 密钥签名让它几乎不那么糟糕
- 如果你在仓库间移动文件，你需要保持历史完整性，使用
git subtree - 提交应该是原子的 – 所有代码、测试和配置更改都应该在里面
- 我花费相当一部分时间确保每个提交原子地通过 CI 检查
- 一些人做了可怕的事情，比如把他们的实现代码和测试代码分离
- 将文档放在单独的提交中是可以的 – 我们不必在一个提交中交付一个完整的端到端功能
- 使用 squash-merge 的仓库很糟糕
- 作为开源项目的维护者，我喜欢 squash-merge，这样我可以重写贡献者的提交消息
- 有时候不值得指导怎样写一个给定的提交消息
- 你周围的人影响你写提交的方式
- 预先做好功课，使你的历史原子化
- 事后将一个大提交分割成原子提交要痛苦得多
- 原子地分割工作对于改善你的奖励驱动很有好处 – 你可以完成更多事情
- 原子提交与 prefactoring 非常搭配
- 有时候，重构的提交可以分到不同的 PR 中（特别是如果使用了 squash-merge）
- 编写提交信息可能比实现需要更长的时间
- 提交信息的长度可能比提交中改动行数的数量级还要大
- 如果你在提交信息中写了很多“和”或者“也”，你可能尝试做了太多事情
- 在过去通过 Git 提交历史的翻阅帮助解锁了许多案例，我可以在没有原作者在场的情况下理解 为什么
- 提交信息是反思你所做的事情不仅仅是什么，更重要的是为什么的绝佳时刻
- 为什么比什么更重要 – 任何人都可以查看差异并大致弄明白做了哪些更改，但背后的意图是特别的调味料
- 如果你只写了发生了什么改变，那你很令人讨厌，我不喜欢你
- 解释了什么的提交比只有“修复”字样的提交更好
- Chris Beams 的文章，如何写一个 Git 提交信息 仍然是一篇出色的文章，距今将近 10 年了，这是一个很好的起点！
- 提交是提交者对假设和世界状态的时点解释。不要对他们太苛刻
- 我不想阅读你的更改的 AI/LLM 重写版本 – 要么自己写，要么就称之为
Various fixes - 需要有一种方法可以添加注解（可能使用
git notes），来更正之前消息的假设 - 我不会一开始就写完美的提交信息 – 有时它们可能就像
rew! add support for SBOMs或sq，或者使用git commit --fixup - 通常，我会将非常好的原子性工作块分解为提交
- 有时我会将原子提交分解为多个提交
- 确保在你将代码更改发送给合作者审阅之前，你已经审查了自己的代码更改
- 审查你的提交信息应该和审查代码变更一样重要
- 让所有的贡献者对提交历史投入同样的关心是一场输仗
- 试图管理提交历史将会很痛苦
- 试图强制在代码审查中审核提交信息将会很痛苦
- 试图管理提交历史确实会导致对变更的文档和考虑水平的提高
- 使隐式假设显式化真的很有用
- 引入
commitlint可能有用，但也可能令人沮丧 - 让你的合作者自愿写好提交信息总比强迫他们来得更好
- 有些人就是不写，这也没关系
- 写作是一种技能
- 我在写作（提交信息）上不是完美的
- 有时我懒得写完美的信息
- 有时我写了一些真正棒极了的提交信息，给自己留下了深刻印象
- 使用 你的 Git 提交信息的模板 是促使正确做事的一个好方法
fixup提交 和git rebase --autosquash是我学到的最佳 Git 技巧之一- 我重视在一个具有多样化视角、技能和工作方法的团队中工作
- 但我也真的很重视拥有一个编写原子提交和良好提交信息的团队
- 编写提交信息和撰写精炼的用户故事/票据一样有用
git commit -m sq可能是我运行最多的命令- 使用
git add -p和git commit -p对于原子提交非常重要 - 永远不要使用
git add -u或git add . - 学习何时可以使用
git add -u或git add . - 我真的需要研究像 Graphite、
git-branchless等工具，以及其他提供堆栈式 PR 设置的方法 - 结合使用 规范提交 和 semantic-release 或 go-semantic-release 在希望自动化和频繁发布时可以产生巨大变化
- 将 常规提交 作为你提交的框架非常有用
- 对于有 ADHD 的人来说，使用 常规提交 可以减少思考的需要，让你更多地关注变更本身
- 使用 常规提交 可以帮助你弄清楚何时一个提交尝试做了太多事情
- 我通过写作来 思考，所以提交消息有助于理解 我为什么做这件事
- 撰写一个好的提交信息，可能比存储在别处的文档更好
- 撰写一个好的提交信息，可能比代码注释更好
- 给人们学习的空间
- 给人们失败的空间
- 记住你曾经也不那么出色
- 文档很酷。多做一些