Git 提交历史太乱？教你清理并规范 commit message

在日常的 Git 开发协作中，你是否遇到过这样的情况：功能分支上反复提交了多个"补丁式"提交（如"修复 typo"、"忘记提交文件"），最终导致提交历史杂乱无章、难以追溯？这不仅让 git log 失去了应有的可读性，也让 Code Review 变得低效且痛苦。

本文将系统性地为你梳理如何通过规范提交信息、使用 rebase、merge --squash、reset 等命令，以及借助自动化工具，将零散、不规范的提交历史整理成清晰、逻辑完整、易于回溯的版本记录。无论你是刚接触 Git 的新手，还是希望提升团队协作效率的老手，都能从中找到实用的解决方案和最佳实践。

一、提交规范

<type>(<scope>): <subject>

• 注意冒号（英文） : 后有空格

scope选填表示commit的作用范围，如数据层、视图层，也可以是目录名称

subject必填用于对commit进行简短的描述

type必填表示提交类型：

feat - 新功能 feature
fix - 修复 bug
docs - 文档注释
style - 代码格式(不影响代码运行的变动)
refactor - 重构、优化(既不增加新功能，也不是修复bug)
perf - 性能优化
test - 增加测试
chore - 构建过程或辅助工具的变动
revert - 回退
build - 打包

二、解决提交不干净、不规范

在功能分支上开发时，多次提交中包含"补丁式提交"（比如"忘记提交的文件"、"修复上一次的 typo"），导致提交历史不干净、不规范

解决目标：

• 合并多个"补丁式"提交为一个逻辑完整的提交。

• 重命名提交信息，使其规范、清晰。

• 最终推送到远程分支时，提交历史干净、可读、便于 Code Review 和回溯

1. 方案一：

1.1. 查看提交历史

git log --oneline

输出：

dace4a8 (HEAD -> testBase, origin/testBase) feat: 其他模块提交
635804e fix: 样式修改
64e9d01 fix: 去除调试代码
1aee000 fix: 第一次提交的补丁
21b9b13 feat: 测试假设一次大的提交
a1caa06 feat: 新分支第一次提交

假设想把 21b9b13 和他的补丁代码合并成为一个完整功能的提交

1.2. 启动交互式变基

这里从 a1caa06 之后开始

git rebase -i a1caa06

会打开编辑器，现实如下内容：

pick 21b9b13 feat: 测试假设一次大的提交
pick 1aee000 fix: 第一次提交的补丁
pick 64e9d01 fix: 去除调试代码
pick 635804e fix: 样式修改
pick dace4a8 feat: 其他模块提交

1.3. 修改指令整理提交

当我们想把三个fix合并到 f7f0097 形成一个完整的提交，我们可以这样改：

pick f7f0097 feat: 这是一次大的改动
s 14f3ec6 fix: 对上一次提交的补丁
s 0cd3e04 fix: 忘记去掉调试的代码了
s f9491c1 fix: 样式修改
pick 0eab36a feat: xxx需求开发完成

squash（或简写 s）：将该提交合并到上一个 pick 的提交中，并让你编辑合并后的提交信息。

保存并关闭编辑器

1.4. 编辑合并后的提交信息

Git 会再次打开编辑器，让你编辑合并后的提交信息：

# This is a combination of 4 commits.
# This is the 1st commit message:
feat: 测试假设一次大的提交
# This is the commit message #2:
fix: 第一次提交的补丁
# This is the commit message #3:
fix: 去除调试代码
# This is the commit message #4:
fix: 样式修改
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
feat: 完整实现XXX功能（含xx、xx、xx）

保存关闭

1.5. 强制推送（注意：仅限未被他人使用的分支）

git push origin feature/xxx --force-with-lease

推荐使用 --force-with-lease 而不是 --force，它更安全 ------ 如果别人在你之后推送了代码，会拒绝强制推送，避免覆盖他人工作

1.6. 整理效果

c58c94a (HEAD -> testBase, origin/testBase) feat: 其他模块提交
ec9cfef feat: 测试假设一次大的提交 // 已经被合并
a1caa06 feat: 新分支第一次提交

方案二：使用合并时压缩提交

2.1 创建新分支并合并压缩

 # 从要整理的提交之前创建一个新分支
git checkout -b clean-branch a1caa06

# 将原分支合并到新分支，并压缩所有提交为一个
git merge --squash testBase

# 此时所有更改都已暂存，创建新的提交
git commit -m "feat: 完整实现XXX功能（含xx、xx、xx）

2.2 方案二变体：选择性合并

 # 创建新分支
git checkout -b clean-branch

# 使用cherry-pick选择需要的提交
git cherry-pick 21b9b13  # 基础提交
git cherry-pick 1aee000  # 补丁1
git cherry-pick 64e9d01  # 补丁2
git cherry-pick 635804e  # 补丁3

# 重置到cherry-pick之前的状态，但保留更改
git reset --soft HEAD~4

# 重新提交为一个完整的提交
git commit -m "feat: 完整实现XXX功能（含xx、xx、xx）"

# 继续添加其他提交（如果需要）
git cherry-pick dace4a8  # 其他模块提

方案三：使用reset整理提交历史

3.1 软重置后重新提交

 # 1. 查看要合并的提交范围
git log --oneline

# 2. 重置到要合并的第一个提交之前（保留工作区更改）
git reset --soft a1caa06

# 3. 暂存所有更改并创建新提交
git add .
git commit -m "feat: 完整实现XXX功能（含xx、xx、xx）"

# 4. 添加后续的提交（如果需要）
git cherry-pick dace4a

方案四：使用Git Extensions或SourceTree等GUI工具

对于不熟悉命令行的用户，可以使用图形化工具：

1. Git Extensions：右键提交 → "交互式变基"

2. SourceTree：右击提交 → "交互式变基子菜单"

3. VS Code GitLens扩展：提供可视化的rebase界面

最佳实践建议

1 提交信息规范

1.1 开发时的提交策略

 # 开发时频繁提交（本地）
git add .
git commit -m "WIP: 正在开发XX功能"

# 功能完成后整理提交
git rebase -i HEAD~5  # 整理最近5个提交

# 推送前确保提交历史整洁
git log --oneline --grap

1.2 分支管理策略

 # 1. 功能分支从develop分支创建
git checkout -b feature/xxx develop

# 2. 开发过程中定期rebase develop分支
git fetch origin
git rebase origin/develop

# 3. 完成功能后整理提交
git rebase -i develop

# 4. 推送到远程
git push origin feature/xxx --force-with-leas

1.3 团队协作注意事项

1. 私人分支：可以自由使用force push

2. 共享分支 ：避免force push，或使用--force-with-lease

3. 主干分支：禁止force push

4. 代码审查前：整理提交历史，便于review

自动化工具推荐

1. 提交信息校验

使用commitlint：

 # 安装commitlint
npm install --save-dev @commitlint/config-conventional @commitlint/cli

# 配置.commitlintrc.js
module.exports = {
  extends: ['@commitlint/config-conventional']

2.GitHub Copilot / Cursor / CodeWhisperer

可根据代码变更建议提交信息（需手动确认）。

示例：在 VS Code 中，Copilot 有时会在你 git add 后提示 "Write a commit message"。

总结对比

方案	优点	缺点	适用场景
交互式变基	最灵活，可精确控制	命令复杂，容易出错	精确整理提交历史
合并压缩	简单易用	失去中间提交记录	快速合并整个分支
reset重置	操作直接	风险较高	从头开始整理
GUI工具	可视化操作	功能可能有限	不熟悉命令行的用户

推荐流程

 # 1. 开发时频繁提交（本地）
echo "进行开发工作..."

# 2. 完成一个功能模块后整理
git add .
git commit -m "feat: 添加用户登录功能"

# 3. 发现需要修复
git add .
git commit --fixup HEAD  # 自动标记为fixup

# 4. 定期整理
git rebase -i --autosquash origin/main

# 5. 推送前检查
git log --oneline --graph --decorate

# 6. 安全推送
git push origin feature/login --force-with-leas

通过上述方案和工具，可以确保提交历史的整洁性，提高代码审查效率，便于项目维护和问题回溯。