lazygit 规范提交记录 背景随着项目的进程，我们经常面临一个问题：发现之前的代码有bug，但是我不知道当初为什么这么写，如果改了会影响哪些？会不会把原来改好的bug又改出来了。我们可以通过 git 的提交记录来查看当初为什么改的。但是 git 提交记录的增长，一个文件提交记录可能有成千上万，要是从头到尾找一遍不知道要找到什么时候。更糟糕的是，好不容易找到了结果提交记录就一条 update at 2026/01/29。这种情况着实令人抓狂。要防止这种情况，我们可以从两个方面着手：要求整个团队规范git 的提交记录在IDE中能快速找到每行代码对应的提交记录规范提交记录git 原版的提交信息模板提交记录我们可以采取国际通用的 Conventional Commits (约定式提交)。它的格式如下:<类型>(影响范围): 一句话总结 <空行> [正文：详细解释为什么这么做，解决了什么痛点] <空行> [脚注：关联的任务单号 ID]正文部分我希望用 Why、How 这两个关键词，也就是为什么要改，如何改。git本身支持自定义 commit 信息的格式，我们可以将一个模板添加到 ~/.gitmessage。然后通过命令git config --global commit.template ~/.gitmessage来指定使用定义的模板，这里我定义的模板如下:<type>(scope): <subject> # --- 为什么修改 (Why) --- # 描述导致问题的现象，或为什么要增加这个功能 # --- 解决方案 (How) --- # 简述核心算法或处理逻辑 # --- 关联单号 --- # Fixes: #这里的 <type> 可以是修改的类型，这个部分是必须的，我一般喜欢定义这么几种类型bugfix (修改bug)feature (添加新功能)doc (更新文档或者注释)forspell (拼写修改)scope 代表的是影响范围，可以根据项目情况灵活的定义，例如在一个前后端分离的项目中，可以定义范围为UI、数据传输、权限等等模块最后的 subject 就是一句话总结，例如"修改普通用户可以访问其他用户隐私文件的bug"后面我可以通过 git commit 来触发模板，后续通过git 默认的编辑器(一般是vi 或者 nano)。lazygit 的配置lazygit 本身也支持自定义配置，它主要通过 config.yml 文件配置，默认的配置文件位置如下:Windows: %LOCALAPPDATA%\lazygit\config.ymlMacOs: ~/Library/Application Support/lazygit/config.ymlLinux: ~/.config/lazygit/config.yml我们可以通过一个命令快捷键触发一个规范化提交的功能。用户自定义命令的模板可以在这里找到。它以 customCommands 作为根节点。后面接 key，command 和 prompts。各个部分的含义如下:key: 用来触发命令的快捷键command: 真实触发的命令prompts: 触发时的行为prompts 是另一个根节点，用于定义详细的行为。它的子元素如下:type: 输入项的类型，有 menu 表示下拉列表框；input代表输入框；menuFromCommand根据用户提供的外部shell命令来生成一个下拉列表框title: 输入框的标题，提示我们这个框用来输入什么信息key: 在command中，需要填入一些数据，我们暂时利用占位符来表示，key代表的是某个具体占位符，需要与占位符对应如果我们的类型是 menu 的话，还需要利用 options 标签来表示具体的选项。最终我的配置如下:customCommands: - key: 'X' command: "git commit -m '{{.Form.Type}}{{.Form.Scope}}: {{.Form.Subject}}' -m 'Why: {{.Form.Why}}' -m 'How: {{.Form.How}}' -m '用例文档或者jira单: {{.Form.TestCase}}'" context: 'files' description: '规范化提交 (Gitmoji + Scope)' prompts: - type: 'menu' title: '选择提交类型 (Type)' key: 'Type' options: - name: '✨ feat (新功能)' value: '✨' - name: '🐛 fix (修复Bug)' value: '🐛' - name: '🚀 更新流水线或者部署脚本' value: '🚀' - name: '📝 docs (文档修改)' value: '📝' - name: '⚡ perf (性能优化)' value: '⚡' - name: '🎨 style (格式/美化)' value: '🎨' - name: '🍎 修复苹果系统上的问题' value: '🍎' - name: '🐧 修复linux 系统上的问题' value: '🐧' - name: '🏁 修复Windows上的问题' value: '🏁' - name: '🤖 修复安卓上的问题' value: '🤖' - name: '⬆️ 升级依赖' value: '️⬆️' - name: '⬇️ 降低依赖' value: '⬇️' - name: '♻️ 代码重构' value: '♻️' - name: '➕ 添加依赖' value: '➕' - name: '➖ 删除依赖' value: '➖' - name: '⏪ 代码回滚' value: '⏪' - name: '🔀 代码合并' value: '🔀' - name: '👽 因外部API改动而更新代码' value: '👽' - type: 'menu' title: '选择影响范围 (Scope)' key: 'Scope' options: - name: 'layout' value: '(layout)' - name: 'render' value: '(render)' - name: 'data' value: '(data)' - name: 'none (无特定范围)' value: '' - type: 'input' title: '简短总结 (Subject)' key: 'Subject' - type: 'input' title: '为什么修改 (Why)' key: 'Why' - type: 'input' title: '具体做法 (How)' key: 'How' - type: 'input' title: '用例文档或者jira单 (TestCase)' key: 'TestCase'在command 中利用git命令来生成一条记录详细提交信息的内容。{{}} 中包裹的都是占位符， .Form.Type 表示这部分内容来自用户后续提交的表单项 Type 中的内容。后续在 prompts 中某一个key的名称需要为 Type 以便进行对应上述提交的内容我仍然采用 Conventional Commits 的格式，首先 type 部分我采用 gitmoji 中规定的符号来表示提交的类型。影响范围我根据我当前的项目模块暂时定了 layout、render、data 等范围。正文部分我提供了三项，即 Why、How、TestCase表示为什么这么改，可以描述一下bug现象，产生的原因。How 表示如何修改的，可以简短的描述一下算法或者具体修改项。最后加上一个用例或者bug管理系统中的单子，因为我公司采用的是jira，所以这里我可以关联上jira单号IDE 中查看提交记录因为我在公司中主要采用 Visual Studio 和 Visual Studio Code，所以这里主要介绍它们上面可以使用的插件，至于我钟爱的NeoVim 和 Emacs，我还没来得及研究，暂时不介绍它们的配置了Visual Studio 中可以使用 Git Line Blame 插件。Visual Studio Code 上可以使用 GitLens 它们的作用都是显示光标所在行对应的提交记录。它们的效果各位读者可以自行到插件官方文档中找到截图。我们在上面记录了测试用例或者bug 单子的另一个好处时可以根据测试用例和bug单快速查找与之相关的提交记录。可以使用下列命令git log --grep jira-111实际上它就是一个 grep 过滤，如果使用管道加 grep ，它只会找到对应的输出无法关联到具体的提交记录，但是通过git log 提供的grep它会显示匹配上的具体的提交记录到此我觉得已经可以解决我个人的问题了，不知道上述内容对各位读者是否有用。各位读者如果有更好的想法可以在评论区留言，欢迎读者给我介绍新的解决思路