凌晨三点，四周安静得只剩主机风扇在转，屏幕上那一行git push终于不再报错，提示main分支已经更新。我长出一口气，把提交记录里的日期看了又看，想着这已经是这个月第几次在这个时间点把自己从某个深渊里捞出来。
做程序员这些年，我越来越觉得“提交”这两个字分量很重。它不只是git commit那一下，而是一个程序员跟代码、跟团队、跟过去的自己对话的方式。一次规范、干净、可追溯的提交，能救未来的自己一命；一次随意、混乱、夹带私货的提交，能坑得整个团队连加三天班。所以当有人把这篇东西称为“自我救赎”时，我真觉得一点不夸张——凌晨三点的提交，救的是那个差点被自己写的烂摊子活埋的人。
这篇文章不聊虚的。我想围绕“提交”这件事，把项目里真正管用的习惯、命令、报错排查和团队规范整理出来。这些内容适合刚入行还在被git折腾的初级程序员，也适合带团队之后发现提交记录一团乱麻的技术负责人。你会发现，提交这件事练好了，代码review会顺很多，回溯问题会快很多，连睡觉都能踏实很多。
1. 提交这件小事，为什么值得较真
很多人把提交当成一个“存个档”的动作，差不多就得了。我刚开始也是这么想的。直到有一次线上出了问题，需要回滚某个功能，结果发现相关提交的 message 写着“fix”，commit里改了一百多个文件，既有格式化又有业务调整还有依赖升级。那一瞬间我真想穿越回去打自己一顿。
提交的意义，远不止保存代码。它是在给项目写编年史。每个 commit 都是项目历史上一个节点，将来不管是排查 bug、做 code review、回滚版本，还是新人接手，第一件事就是翻提交记录。提交信息写得好不好，直接决定这条历史是清晰还是糊涂。
再往深一层说，提交是一个程序员的思考切面。能在一个提交里做好一件事的人，写代码时脑子里多半是清醒的；而那些一个提交塞十件事的人，代码里往往也是剪不断理还乱。很多团队不重视提交规范，最后付出的代价远比想象中大——代码回溯难、责任界定难、自动化发布出问题也难定位。
那到底什么叫“好提交”？我自己的标准有三个：最小化、可追溯、可独立通过验证。
最小化，就是一个提交只做一件事，改动范围越小越好。可追溯，是提交信息能把“为什么改”说清楚，而不仅仅写“改bug”。可独立通过验证，是每个提交拿下来都能编译、能跑测试，而不是拆成一百个相互依赖的碎片。
你可能会问，这跟凌晨三点的提交有什么关系？关系太大了。凌晨本身不是重点，重点是当你被一个问题困到深夜，你拼命想赶在deadline前修复，仓促之间做出的提交往往最危险。这时候如果你心里有一套明确的提交规则，就会像抓住一根绳子一样，逼着自己慢下来，把问题拆开、把提交理清，反而比急急忙忙乱推一通更能稳住局面。
1.1 提交信息是写给人看的，不是写给机器看的
git commit -m "update"这种提交信息能跑通，但毫无价值。机器只需要哈希值就能定位版本，提交信息是留给人的。三个月后你回头看，看到“update”一头雾水；你同事看完，心里只想骂人。
我一般用这么一套格式：type(scope): subject。type 是提交类型，scope 是影响范围，subject 是对这次改动的简要说明。比如fix(auth): 修复登录态过期后跳转异常，你一眼就知道这个提交动了什么、为什么动。如果是破坏性变更，后面可以加BREAKING CHANGE:备注。这不是某一家公司的规定，是社区里通用的 Angular 规范演化出来的习惯，很多团队的commitlint配置都基于这一套。
type 的常见选项里，feat是新功能，fix是修 bug，docs是文档，style是格式调整，refactor是重构，test是测试相关，chore是杂项，比如改构建配置、升级依赖。别小看这个分类，它不仅能让人快速过滤目标提交，还能配合工具自动生成 changelog。我见过不少团队发布前手工整理更新日志，整理得人仰马翻，其实提交信息规范之后，changelog 基本可以自动化生成。
1.2 一次提交只做一件事，别把变更揉成一团
这是我踩过最大的坑。以前我改一个功能，经常捎带把附近不相关的代码也整理一下，顺手再升级个小依赖。提交时嫌麻烦，全塞在一起。后来 review 的同事问“你这个提交为什么改了三个模块”，我才意识到问题有多严重。
一个提交应该像一篇文章的一个段落，只表达一个意思。如果做代码检查时发现格式问题，就单独开一个 style 提交；要升级依赖，就单独开一个 chore 提交；业务逻辑调整，就单独开一个 fix 或 feat 提交。这样出了问题可以单独 revert 某一个提交，而不会把其他改动一起牵扯进来。
实际操作中，我习惯先用git status看清楚改了哪些文件，然后用git add精确添加，而不是无脑git add .。文件太多时，我会git add -p一段段确认。刚开始觉得麻烦，习惯了反而觉得心里有底，因为每 add 一次，我都会下意识想一遍这次提交的 message 是什么，想不清楚就说明改动塞得太多了。
2. 提交现场：从手忙脚乱到一套顺手流程
说完了理念，落到实操上。我带过不少新人，发现大家最常卡的其实不是大原理，而是日常操作不顺畅。比如提交之后发现有不想提交的文件，刚提交完发现 message 写错了，push 上去之后发现漏了文件，合并时冲突一大片。这些细碎问题会消耗大量精力，攒多了就会变成“凌晨三点还在搞提交”的元凶。
所以我想把整套提交流程梳理一遍，从新建分支到最终 push，每一步给出我常用的命令和理由。这套流程不是什么金科玉律，但它至少能帮你避开一批最常见的坑。
2.1 提交之前，先把工作区收拾干净
我见过太多人一上来就提交，结果把乱七八糟的文件全提交上去了。比如编辑器生成的临时文件、本机配置文件、编译产物，这些都进了仓库，后面清理起来特别恶心。
解决思路是提前用.gitignore把不该入库的东西挡在门外。Java 项目要挡target/、*.class，Python 项目要挡__pycache__/、.venv/，Node 项目要挡node_modules/。别等出了问题再补，项目初始化第一件事就先写好.gitignore，后面能省下大把时间。
提交前我固定看一眼git status。扁平成两列输出，一列是暂存区，一列是工作区。这个操作很多人觉得多余，但我觉得这是给大脑一个“当前状态快照”。确认了哪些文件是新增、哪些是修改、哪些被删除，再git add才不会出错。另外，git diff也是提交前的好帮手，它会逐行展示改动内容，我习惯在 add 之前先 diff 一遍，确认没有把调试用的临时代码带进去。
2.2 提交信息怎么写：把“为什么”写进 message
每次提交，我会花十几秒想 message。这不浪费时间，是在为未来省时间。一条好 message 不需要很长，但要把“为什么”说明白。
举个例子，同样是修一个按钮点击没反应的问题：
- 差：
fix - 中：
fix button - 好：
fix(login): 修复登录按钮在 Safari 下点击无响应的问题
最后一条好用在哪？第一，fix说明了这是修复；第二，login标明了影响范围；第三，具体到“Safari 下点击无响应”，将来任何人排查到这个提交，都能立刻判断跟自己的问题是否相关。
有些人会在 message 里写很长的背景说明，甚至关联 issue 编号，这也很好。提交信息本身没有字数限制，git commit不加-m会打开编辑器，可以在里面写正文。我有时候写重要提交，会用多行 message，第一行是标题，空一行后写正文，解释为什么做这个改动、用了什么方案、有没有备选方案。这种提交追溯起来特别舒服，等于给未来的自己留了一张手写纸条。
2.3 一套能应对大部分场景的日常提交命令
下面是我日常用到的组合，按顺序排下来基本够用。场景是：你有一个干净的 main 分支，现在要开发一个功能并最终提交代码。
# 1. 先拉取最新的远端代码，保持基线新鲜 git checkout main git pull origin main # 2. 从最新 main 切一个功能分支 git checkout -b feature/user-login # 3. 开发过程中随时查看状态 git status git diff # 4. 逻辑完成，按改动粒度分步提交 git add src/controller/login.js git commit -m "feat(login): 新增登录接口及校验逻辑" git add src/utils/validator.js git commit -m "refactor(validator): 抽离通用参数校验方法" # 5. 推送分支到远端 git push -u origin feature/user-login # 6. 如果远端代码有更新，合并 main 到当前分支 git fetch origin git merge origin/main这里重点说-u参数。第一次 push 新分支时，git push -u origin 分支名会把本地分支和远端分支关联起来，之后直接git push和git pull就行了，不用每次写全名。很多新手 push 不上去，发现不是权限问题而是没加-u，远端不知道该把分支推到哪。
我自己的习惯是：小改动直接在 main 上改没问题，但只要是稍微成形的功能，就开分支。开分支不费事，却能把“未完成的东西”和“稳定的东西”隔离开，避免把做一半的代码直接暴露给队友。等到功能完整了，再合并回来，提交历史也好看很多。
3. 提交翻车现场：这些年遇到的那些报错和乌龙
写代码哪有不出错的。提交这件事也一样，我敢说每个程序员都经历过push 被拒、冲突一片红、提交之后发现少了文件的时刻。这一节我挑几个高频问题，把排查思路和解决办法讲透。
3.1 提交作者不对：commit author is not 这类问题
这是一个经典报错。常见场景有两种：一是你用公司邮箱注册了 GitHub，但本地 git 配置的是个人邮箱，push 时被平台拒绝；二是你在一台新电脑上没配置 user.name 和 user.email，git 用了一个默认值，导致提交记录里的作者变成一串奇怪的字。
报错信息经常长这样：commit author is not ...。不用慌，它不是说你代码有问题，而是说“你的提交身份不被远端仓库认可”。
解决办法分两步。先看看本地配置：
git config user.name git config user.email如果输出的不是你想用的身份，重新设置：
git config user.name "你的名字" git config user.email "你的邮箱"不加--global只对当前仓库生效，加--global则对这台机器所有仓库生效。我个人的习惯是在每台新电脑上第一时间配置--global，并且三台设备用同一套 name 和 email，避免不同设备提交出不同作者。
如果是提交已经打出去了，但作者信息错了，需要改历史。还没 push 的可以改，已经 push 的需要谨慎。改最近一条提交的作者：
git commit --amend --author="你的名字 <你的邮箱>" --no-edit如果有多条历史要改，就得用git rebase加exec逐一改。这个操作会重写历史，push 时基本要强制推送，对共享分支有风险，所以我只建议在自己私人分支上操作。共享分支上遇到作者信息问题，我宁可在提交信息里加一行备注说明实际作者，也不去重写历史。
3.2 push 不上去：远端领先、权限不足、网络卡顿
git push推不上去，是高频问题中的高频问题。拆开讲大概三类原因。
第一类是远端领先。你本地基于旧版本改了代码，但远端 main 已经有别人推的新提交，git 出于安全考虑拒绝你的快进式推送。解法是先把远端最新代码拉下来合并或变基，再重新 push。
git pull --rebase origin main git push origin main这里我推荐--rebase而不是默认 merge，它能让你本地的提交“接到”远端最新提交之后，历史是一条直线，不会有乱七八糟的 merge 节点。如果变基过程中有冲突，解决完用git add后执行git rebase --continue接着走。实在搞不定还能git rebase --abort回到变基前状态，很安全。
第二类是权限不足。比如你尝试推到别人的仓库，或者给没有写权限的分支推送。解法是先git remote -v看看远端地址对不对，再确认一下当前分支是不是受保护分支。GitHub 上 main 分支默认就受保护，不是所有操作都能直接推。
第三类是网络问题。git push -u origin main一直提交不上去，有时候纯粹是网络连不上远程服务器，或者代理没配置对。可以先git ls-remote origin测一下能不能连通，连不通就从网络角度排查。这个报错本身不一定有代码层面的问题。
3.3 换行符和格式化带来的虚假冲突
还有一种冲突让人特别崩溃：看起来每行都冲突，实际上代码根本没改。这种通常是换行符差异导致的。Windows 下 git 默认会把 CRLF 转成 LF 存储，但不同人的编辑器设置不一致，容易造成整文件冲突。
一个比较通用的处理方式是给仓库加.gitattributes，统一声明换行符规则：
* text=auto *.sh text eol=lf *.bat text eol=crlf这样不管开发者用什么编辑器，git 在存储时都能保证一致，从源头上减少“虚假冲突”。这类问题排查起来特别花时间，最好提前配置好，等团队里有人踩坑再处理就晚了。
3.4 冲突解决：别慌，先看清结构
冲突是 git 里最让新手恐慌的词，但真正理解了结构就不难。冲突出现时，文件里会有类似这样的内容：
<<<<<<< HEAD 这里是当前分支的代码 ======= 这里是合并进来的分支的代码 >>>>>>> feature/user-login你要做的就是在这两段之间做选择或融合，然后把标记符号删掉。可以保留左边、保留右边、两边都要，也可以手动改写。改完之后，git add这个文件，再git commit完成合并提交。
我解决冲突有个习惯：先git log看看冲突涉及的两条线各自改了什么，理解双方的意图，而不是机械地挑一行。因为有时候看起来冲突的代码，实际上两边是在解决不同的问题，正确的做法是同时保留并做适配，而不是二选一把某一方的逻辑杀掉了。实在拿不准，就找对端提交的人问一下，总比自作主张强。
4. 提交补救：已经提交了，还能怎么救
提交错了不等于完了。git 的灵活之处就在于，它允许你在一定范围内重写历史。锤子拿起来之前，先搞清楚哪些操作安全、哪些操作危险，别把整个仓库搞崩。
4.1 改最近一次提交：amend 的边界与用法
git commit --amend是我日常用得最多的补救命令。它可以修改最近一次提交的信息，也可以把漏掉的文件补进最近一次提交，前提是这个提交还没被推到远端，或者你并不介意改写这条历史。
想改 message：
git commit --amend -m "新的提交信息"想把漏掉的文件补进去：
git add 漏掉的文件 git commit --amend --no-edit加了--no-edit会保留原来的提交信息，只把文件补进去。注意，amend 会生成一个新的 commit 哈希，所以这条提交之前的 push 记录会失效。如果这个分支上只有你一个人干活，push 到远端后用git push --force-with-lease就能覆盖；如果分支上还有别人在基于旧提交开发，amend 之后就会坑到别人。所以我的边界是：本地没 push 的提交随便 amend，已经 push 且别人可能拉过这个分支的，不 amend。
4.2 改多条历史：rebase 交互模式的正确打开方式
需要改的不是最近一次，而是前几次提交，或者想把几条提交合并成一条，这时候用交互式 rebase。
git rebase -i HEAD~3这条命令会打开一个交互界面，展示最近三条提交。你会看到类似这样：
pick 1a2b3c4 feat(auth): 新增登录接口 pick 5d6e7f8 fix(auth): 修复登录校验bug pick 9a0b1c2 refactor(auth): 提取token解析工具如果你想把后两条合成一条，把第二第三行的pick改成squash，保存退出，git 会一步步让你编辑合并后的提交信息。同样的，rebase 会重写这些提交的哈希，已经 push 过的历史要同样用--force-with-lease推上去。
我特别提醒：rebase 交互模式的编辑界面默认是 vim。新手第一次进去往往不知道要按i进入编辑模式，改完按Esc再输入:wq保存退出。卡在这一步的人太多了，我把这个写出来，希望你能少走点弯路。
4.3 只挑某几个提交：cherry-pick 的妙用
还有一种场景：你在一堆提交里只想把某一个功能挪到 release 分支，或者只想把某个修复同步到当前分支，这时候cherry-pick比 merge 精准得多。
git cherry-pick 提交哈希这条命令会把指定的提交“复制”一份到当前分支上，生成一个新的提交。比如你在develop上修了一个紧急 bug，提交哈希是abc123，现在想把这个修复也合到main上，切到 main 然后 cherry-pick 就行。
需要挑选多个提交时，可以一次传多个哈希：
git cherry-pick abc123 def456也可以按范围挑选：
git cherry-pick abc123..def456这个范围的含义是“abc123 之后到 def456 之间的所有提交”，不包含 abc123 本身。多个提交之间如果有依赖关系，顺序要排对，不然容易冲突。cherry-pick 遇到冲突时，处理方式和 merge 一样，解决后git cherry-pick --continue继续，放弃就用git cherry-pick --abort。
另外，很多团队推广“提交信息里带上 issue 编号”是有原因的。当你需要从几百个提交里挑出跟某个需求相关的提交时，一个规范的信息能让你用git log --grep=issue编号快速定位。没有规范，就只能一条条翻，翻到凌晨就问你怕不怕。
4.4 push 被彻底卡住时：force-with-lease 比 force 安全
重写历史之后，push 往往会失败，因为本地分支和远端分支的提交路径不一致。有些教程会让你直接git push --force，但我强烈建议用git push --force-with-lease。
区别在于--force会无条件覆盖远端，哪怕远端已经有别人新推的提交，也会被你的本地版本顶掉。--force-with-lease会检查远端在你上次 fetch 之后是否有变化，如果远端出现了你没有的新提交，它就拒绝推送，避免你把别人的工作冲掉。这个机制就像拿着钥匙进房间，锁没换过才让你开；锁被人换过了，宁可停下来也不要硬来。
我用--force-with-lease救过自己好几次，也从没误伤过队友的提交。这是重写历史后的第一选择，不是第二选择。
5. 提交救赎：把规范变成肌肉记忆
技巧学到一定程度，真正拉开差距的是习惯和规范。个人提交再熟练，如果团队不统一，代码库到后来依然会乱成一锅粥。我见过一些团队，提交信息五花八门，分支命名各写各的，代码 review 时花了大量时间讨论“你这提交到底改了什么”。这种内耗，完全可以通过规则消解。
5.1 用工具卡住提交：husky + commitlint 落地规范
光靠自觉不够。人有惰性，凌晨三点的你更是只想赶紧推完睡觉，哪还记得什么规范。所以要用工具在提交那一刻就把关，不规范的提交直接不让过。
前端项目常用 husky 配合 commitlint 实现。husky能让我们在 git 钩子阶段拦截命令，commitlint则根据规则校验提交信息。安装配置大致是：
{ "husky": { "hooks": { "commit-msg": "commitlint -E HUSKY_GIT_PARAMS" } } }commitlint 的规则可以自定义，也可以用官方推荐的 conventional 配置，它对应的正是前面说的type(scope): subject格式。配置好之后，如果有人想提交fix这样不合规的 message，git 会直接拒绝，并提示正确的格式。这比事后 code review 时口头提醒强太多了。
除了 commitlint，还可以在pre-commit钩子里跑代码格式化和静态检查，确保每个提交都至少是“格式干净、没有明显语法错误”的状态。这里想特别说一句，钩子不是越多越好，跑太慢的检查会让人想绕过它。我的原则是：只拦截那些“必错”的情况，把需要人判断的事留给代码 review。
5.2 多设备与项目边界：别让 config 害了提交
很多程序员不止一台设备。公司电脑、个人电脑可能都在提交同一个项目，如果两边的 user.name 和 user.email 不一致，提交记录里就会出现两个“你”，追查责任时容易混乱。
我自己的做法是在全局配置里统一身份，同时用项目的.git/config做特殊覆盖。比如某些开源项目需要匿名身份，或者公司项目要求专用邮箱，我会单独在项目目录下配置，不污染全局。
另外一个跟提交相关的“边界问题”是密钥管理。很多人 push 失败，是因为 SSH key 没配好或者 token 过期。如果本地用 HTTPS 克隆的仓库，push 时会要求输入用户名密码或个人访问令牌，输错了也会被拒。建议提前把 GitHub 或 GitLab 的 token 配置到系统的凭据管理器里，省得每次提交都手输一遍。git 最烦人的地方在于，很多报错信息写得并不友好，事后想想是少了这么一层配置，当时真是查得焦头烂额。
5.3 提交之外：一个程序员的“自我救赎”
说回那个凌晨三点的提交。
那天晚上我本来可以更早结束的，但白天连续几个不规范的提交把问题拖到了深夜。先是有人 push 了一个带冲突的中间态，我又基于这个中间态继续开发，结果怎么跑怎么不对。最后回头清理时，看着那一堆“wip”“fix again”“final update”的提交信息，真有一种被过去的自己坑惨了的感觉。
所以后来我给自己定了几条铁律：写代码前先想清楚改动范围，提交前一定看 diff 确认内容，提交信息必须说清楚“为什么”，push 之前先拉最新的远端代码。这些规矩看起来枯燥，但它们会让你在做每一个操作时都多一分清醒。人不可能永远保持最佳状态，但当规则已经变成肌肉记忆，哪怕凌晨三点，你也不会做出一个让自己后悔的提交。
回过头看，那次凌晨三点的提交并不算多漂亮，但它让我下定决心把“提交规范”当成一件正经事来对待。从那之后，我几乎没有再因为提交混乱而加班排查过问题。代码仓库越来越干净，我自己的状态也越来越稳。这大概就是所谓的救赎——不是靠某个神奇命令一劳永逸，而是靠一个个微小习惯，把本该混乱的流程一步一步理顺。
