Git 进阶技巧：优雅合并初始提交与 Commit 规范详解
在开发过程中，我们经常需要整理 Git 提交记录，使其看起来更加专业和整洁。最近在进行版本发布时，遇到了一个关于合并 Commit 的典型问题，同时也涉及到了业界通用的提交规范。
本文将分两部分解析：首先解释 feat 的含义，其次解决如何将前两个 Commit 合并为一个完美的初始提交。
1. 深入理解 feat：Commit 规范详解
在查看 Git 日志时，我们经常会看到类似 feat(core): release v1.0.0... 这样的提交信息。这里的 feat 到底是什么意思？
什么是 feat？
feat 是英文 feature（新功能） 的缩写。
这套写法源于 约定式提交规范，这是全球开源社区和互联网大厂通行的一种代码提交标准。它的标准格式如下：
text
<类型>(<作用域>): <描述>- feat (类型)：代表这次提交为代码库增加了一个新功能。
- (core) (作用域)：代表这次修改影响的是系统的核心模块。
- release v1.0.0... (描述)：简短说明这次提交的具体内容。
常见的提交类型
除了 feat，还有几种常见的类型需要掌握：
- fix：修复 Bug。
- docs：仅修改文档（例如编写 README）。
- refactor ：重构代码（既没有新增功能，也没有修复 Bug，只是优化代码结构）。
使用这种格式提交代码，能让 Git 历史记录清晰明了，无论是团队协作还是个人复盘，都能一眼看出每次变更的目的。
2. 实战：如何合并前两次 Commit？
场景复现
假设当前的提交记录如下，共有两个 Commit：
text
commit 23840fa... (HEAD -> main)
Author: cyforkk
Date: Thu Mar 26 16:53:11 2026 +0800
feat(core): release v1.0.0 cyforkk-redis-starter
commit ac198b6...
Author: cyforkk
Date: Thu Mar 26 16:52:11 2026 +0800
完成README现在的目标是：将这两个提交"揉"成一个，作为项目的初始提交。
遇到的"坑"
通常我们会想到使用 git reset --soft HEAD~2 回退两步再重新提交。但在只有两个 Commit 的情况下，执行该命令会报错：
text
$ git reset --soft HEAD~2
fatal: ambiguous argument 'HEAD~2': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'原因分析
别慌！这个报错其实揭示了一个 Git 的底层逻辑。
HEAD~2 的意思是"往回退 2 步"。如果你的仓库总共只有 2 个 Commit，Git 发现退 2 步就会退到"宇宙大爆炸之前"（也就是没有任何 Commit 的虚无状态）。因为那个状态没有父节点，Git 无法定位，所以报错提示参数模糊。
解决方案：追加合并法
既然回退两步行不通，我们可以采用更优雅的 "追加合并法" 。
请依次执行以下两步命令：
第一步：往回退 1 步
bash
git reset --soft HEAD~1这行命令会将最近的那个 feat(core)... 提交撤销，代码改动保留在暂存区。此时，仓库状态回到了第一个 Commit（"完成README"）上。
第二步：修改并覆盖第一个 Commit
bash
git commit --amend -m "feat(core): release v1.0.0 cyforkk-redis-starter high-availability middleware"--amend 是 Git 的魔法指令，意为"修正当前的 Commit"。这行命令会把暂存区里的代码（刚才撤回来的部分）与当前 Commit 的内容融合，并使用新的提交信息覆盖旧的记录。
最终结果
执行完毕后，再次查看日志：
bash
git log你会发现原本零散的两个提交已经消失，取而代之的是一个完美、干净的初始 Commit。
确认无误后，就可以去 GitHub 建立远程仓库并执行 git push 操作了。这样不仅解决了报错，还让你的提交历史显得更加专业规范。