这是 Jamie Tanna 于 2024 年 7 月 12 日撰写的文章，约 5 周前就在作者脑海中形成，可能会成为“动态帖子”并随时间更新。

• Git 的用途：Git 有不同用途，如协作工具、备份工具、文档工具。
• Git 提交消息：作者非常喜欢阅读 Git 提交消息，通过提交消息了解变更原因比通过问题/缺陷追踪器更易，有详细的提交消息如“Various fixes. DEV-123”比只有“Various fixes”好，但如果问题本身无有用信息则不好。
• 合并方式偏好：作者偏好 rebase-merging，其次是 squash-merge，最后是 merge，不懂 rebase 会错过一项技能，学会使用git reflog可避免删除仓库和恢复可恢复的工作，也能避免犯错。
• Squash 相关：Squashing 有时浪费好的原子提交，但比 100 个垃圾提交好，合并时写好提交消息较好，不重新编辑消息则糟糕，有 100 个垃圾提交时不重新编辑消息更是“犯罪”，仅写 PR/MR 描述而不用于 squash-merge 消息是浪费时间。
• 其他经验：学习各种花哨工具和命令也不能避免偶尔犯错，如最近的糟糕 rebase 需git reflog帮忙；要学会撤销强制推送和更安全地强制推送；将文档放在单独提交中可以；使用git subtree在仓库间移动文件时保持历史完整；提交应原子化，包括代码、测试和配置更改；有些人会将实现和测试代码分开很糟糕；有时可将预重构提交放入单独的 PR 中；写提交消息可能比实现花费更长时间，消息可能比更改的行数大一个数量级，若提交消息中有太多“and”或“also”可能做了太多事；通过浏览 Git 提交历史可理解变更原因；提交消息不仅是做了什么，更重要的是为什么；不要只写更改内容，要解释原因；Chris Beams 的How to Write a Git Commit Message文章很棒；提交是提交者对假设和世界状态的时间点解释，不要太苛刻；不喜欢 AI/LLM 重写的更改，希望提交者自己写或写“Various fixes”；希望有方法添加注释到先前消息以纠正假设；不会一开始就写完美的提交消息，会拆分好的原子工作为提交；审查自己的代码更改和提交消息同样重要；让所有贡献者对提交历史投入同样的关心是徒劳的，试图规范提交历史会很痛苦，但能提高文档水平；使隐含假设明确很有用，引入commitlint可能有用也可能令人沮丧，更希望合作者主动写好提交消息，有些人不写也没关系，写作是一项技能，作者自己也不完美；使用Git 提交消息模板是个好的提醒；fixup提交和git rebase --autosquash是很好的 Git 技巧；重视团队的多样性和写好原子提交及消息；提交消息写作与写好用户故事/工单一样有用；git commit -m sq是常用命令，使用git add -p和git commit -p对原子提交很重要，不要使用git add -u或git add.，要学会何时使用；想研究 Graphite、git-branchless等提供堆叠 PR 设置的工具；使用Conventional Commits结合semantic-release或go-semantic-release在自动频繁发布时很有帮助，可作为提交框架，有助于判断是否在一个提交中做了太多事，作者通过思考写作来理解为什么做某事，写好的提交消息比文档或代码注释更好；给人学习和失败的空间，记住自己也曾不优秀，要多做文档。