lazygit 规范提交记录

背景

随着项目的进程，我们经常面临一个问题：发现之前的代码有bug，但是我不知道当初为什么这么写，如果改了会影响哪些？会不会把原来改好的bug又改出来了。

我们可以通过 git 的提交记录来查看当初为什么改的。但是 git 提交记录的增长，一个文件提交记录可能有成千上万，要是从头到尾找一遍不知道要找到什么时候。更糟糕的是，好不容易找到了结果提交记录就一条 update at 2026/01/29。这种情况着实令人抓狂。

要防止这种情况，我们可以从两个方面着手：

1. 要求整个团队规范git 的提交记录
2. 在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.yml
• MacOs: ~/Library/Application Support/lazygit/config.yml
• Linux: ~/.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它会显示匹配上的具体的提交记录

到此我觉得已经可以解决我个人的问题了，不知道上述内容对各位读者是否有用。各位读者如果有更好的想法可以在评论区留言，欢迎读者给我介绍新的解决思路