还在用“git 提交代码”把自己绕晕每次 pull、commit、push 的顺序都靠肌肉记忆遇到冲突就头皮发麻别急这篇文章把我自己从 “git 菜鸟” 到 “命令行操作如喝水” 的完整经验整理出来了。不管你是刚入行的新人还是被同事的“乱提交”折磨的队友这篇都能给你一套闭眼可用的标准操作流程。很多初学者甚至部分“熟练工”都觉得 git 难不是因为命令本身复杂而是脑子里没有一套完整的流程。今天我就把这套流程拆开了揉碎了讲从最基础的原理到最容易翻车的冲突解决再到几个我踩坑踩出来的小技巧一次性说清楚。1. 内容整体设计与思路拆解1.1 先搞清楚我们要解决什么问题git 传代码本质上就是解决一个问题如何安全、有序、不丢代码地把本地修改送到远端仓库。听起来简单但实际场景里你很可能遇到过这些情况提交完之后发现漏了一个文件结果又补了一次 commit历史记录里全是“fix typo”、“update”。push 的时候报错提示远端有更新你怕冲突直接强推把同事的代码覆盖了第二天被拉去开会。拉取代码的时候发现冲突不知道怎么处理一顿乱改不光没解决冲突还把不该删的代码删了。这些问题我一个一个都遇到过。后来我总结出一个核心理念git 操作不是靠背命令而是靠理解状态。你只要时刻清楚代码在本地仓库、暂存区、远端仓库这三个位置中的哪一步思路就清晰了。1.2 为什么强烈推荐“先拉再推”的标准动作对于团队协作而言顺序其实非常有讲究。最简单的原则就是“先更新、后提交、再推送”。很多人图省事习惯性直接 commit 然后 push结果远端已经被别人更新过了你的 push 就会被拒绝。被迫 merge 的时候又会引发一堆冲突。所以我个人的习惯是只要准备提交开头必然先git pull --rebase再 commit再 push。这一下就能避免绝大部分无谓的合并记录。当然rebase和merge的选择本身就有很多讲究后面我专门用一节来讲这里先不展开大家记住“先拉再推”这个总原则就行。1.3 核心逻辑工作区、暂存区、本地仓库的关系我一直在想用什么类比来解释 git 的状态最合适后来发现“存钱”这个例子最容易懂工作区Working Directory—— 你手里的现金随便花随便改只要没存进银行都算你自己的事。暂存区Index / Stage—— 你填好的存款单钱已经点了但还没交付到柜台也许你还会想再改改。本地仓库Local Repository—— 你的银行账户一旦 commit 进去这笔钱就有了交易流水不可随意抹除。远端仓库Remote Repository—— 你存进总行的账户其他同事其他分行才看得到、拿得到。理解了这四个概念git 传代码的流程就清晰了在工作区里改代码把要交的东西挑拣进暂存区在本地仓库生成一个不可回退的记录最后推送到远端让别人看见。是不是一下子就通透了2. 核心细节解析与实操要点2.1 初始化与配置别等出错了才想起配置身份很多时候我们拿到一台新电脑或者新项目第一件事就是git init。但你会发现即使你本地初始化成功第一次 commit 也会报错提示你配置 user.name 和 user.email。这是 git 的基本身份校验机制可别想着能跳过它会直接卡住你提交操作。我建议新手在安装完 git 后立刻执行这两条命令做全局配置git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个小细节值得注意--global是全局配置会影响这台电脑上所有仓库。如果你只希望在一个仓库里用特定身份比如公司项目和私人项目分开就在项目目录下执行不带--global的版本。配置完了可以用git config --list检查一下省得后面 push 的时候远端记录里挂着一个奇怪名字。2.2 精准暂存add 的三种境界git add是操作暂存区的命令但很多新手只知道git add .添加所有变更。不是不行而是不够好。直接添加全部文件很容易把调试用的临时文件、本地配置文件、甚至依赖包不小心加进来。这时候.gitignore文件的作用就出来了。我每次新建项目必写.gitignore把node_modules/、dist/、.env、*.log这些通通排除在版本管理之外。在暂存阶段我常用的命令有git add src/ # 添加某个目录 git add app.py # 添加某个文件 git add -p # 交互式逐块暂存非常精致git add -p是最容易被忽略的一个神级命令。它会把你的改动按“块”拆开让你挑选哪些改动需要被暂存哪些暂时不提交。比如你在一个文件里同时改了一个新功能和一行调试日志用-p就能只把功能代码提交上去把调试日志留在工作区。这个命令的熟练程度基本可以算是 git 操作的一个分水岭。2.3 提交的艺术写清楚 commit message 才算真正完成很多人都把 commit 当成“存个档”message 随便写个 “update” 甚至直接留空。说实话这对自己是省事了对同事和以后的自己就是灾难。你想想三个月后你看到一行git log满屏都是“update”你能记得当时改了啥吗我建议遵循业界常用的规范格式大致长这样type(scope): subject常见的 type 包括feat新功能、fix修 bug、docs文档、style格式、refactor重构、test测试等。scope 表示影响范围可以省略。举个例子git commit -m fix(login): 修复密码重置后无法登录的问题这样一行信息任何人都能一眼看懂这次提交做了什么。如果你觉得一行不够描述清楚可以不加-m直接执行git commitgit 会打开默认编辑器让你写多行详细描述。在团队里一份清晰的提交历史就是最好的项目文档。我还特别想提醒一点不要提交你还没有写完的代码。半成品代码提交上去如果同事 pull 下来跑不起来你的 commit 就成了“项目毒药”。宁可放在工作区或者单独的分支上也别打断团队主线。2.4 分支管理别在主分支上裸奔分支这块很多新手和老手的理解程度完全不同。新手完全不用分支一个 master 走天下push 全靠莽。真正经历过多人协作、代码被覆盖、频繁冲突的人才会明白分支就是 git 给你搭的“安全围栏”。我推荐一个稳定好用的“三贱客”分支模型main或master主分支长期存在且保持稳定只能通过合并分支进入不能直接在上面提交。develop开发分支大家日常的工作从这里拉出去分支再合并回来。feature/xxx功能分支比如feature/login-modal、feature/payment-api。你开发新功能就开一个开发完合并后就删掉。每次新开发前我都习惯在最新的develop基础上新建分支git checkout develop git pull origin develop git checkout -b feature/my-feature这样做的绝对好处是你在自己的开发流里为所欲为没人能干扰你。就算代码写崩了删掉这个分支重开一个就行完全不影响主干心理负担大大降低。3. 实操过程与核心环节实现3.1 最经典的完整提交流程演示下面这套流程是我在团队里推行的标准动作几乎适用于所有日常工作场景。我们来模拟一次完整的开发提交流程。假设我在feature/user-center分支上开发了一个用户中心的功能现在要提交代码# 1. 先看一眼当前仓库的状态心里有个底 git status # 2. 切换到自己的分支如果你是新建分支这步会带上 -b git checkout feature/user-center # 3. 把远端最新的代码拉到本地保持基线在同一水平线 git pull origin feature/user-center # 4. 将改动的文件加入暂存区 git add src/pages/user/ src/utils/userHelper.js # 5. 确认已经加入暂存区的文件情况 git status # 6. 提交到本地仓库凝视你的 commit message 三秒再确认 git commit -m feat(user): 新增用户中心个人信息展示与编辑功能 # 7. 推送前再拉一次远端代码防止有新的提交 git pull origin feature/user-center # 8. 推送本地提交到远端 git push origin feature/user-center流程跑完你的代码就安全抵达远端了。注意我在第 7 步又做了一次 pull这其实是双保险策略。很多人可能认为第 3 步已经拉过了没必要再拉一次但实际操作中有时候你第 3 步拉的版本和第 7 步之间的时间窗口里同事可能刚好 push 了内容。多拉一次总比后面处理 rebase 冲突要划算。我从第 3 步的pull多用的是git pull --rebase。上面说了--rebase和默认 merge 的差异很大这里我来补一段完整解释。3.2 深度解析pull 到底该用 merge 还是 rebase这是很多 git 教程里最含糊的一个点。git pull默认等价于git fetchgit merge。也就是说它会把远端的新提交直接合并到你的本地分支生成一个“合并提交”。这样的好处是记录真实缺点也很明显——提交历史会被搞得多叉分叉时间线变得像一团毛线。而git pull --rebase等价于git fetchgit rebase。它会把你本地尚未推送的提交“摘下来”接到远端最新的提交之后就像你的代码总是在最新代码之后修改的一样整个历史是一条干净直线。我个人的标准是在你的个人功能分支上用 rebase在公共的 develop/main 分支上用 merge。这样既保持了个人分支的整洁又避免在公共分支上重写提交历史导致其他同事的“操作历史”被更改。如果 pull 的过程中出现冲突rebase 的处理方式也稍微复杂一点不过别担心下面会专门讲。3.3 实战演示完整演示 rebase 下的冲突处理假设现在我在feature/user-center分支同事往develop分支提交了一个修改而且恰好改的是同一个文件。我的操作如下# 在 feature 分支执行 git pull origin develop --rebase执行之后git 会提示冲突CONFLICT (content): Merge conflict in src/utils/userHelper.js这时候不要慌。执行git status你会看到这个文件被标记为both modified。打开文件你大概率会看到这样的内容 HEAD const AGE_LIMIT 18; const AGE_LIMIT 21; develop (commit message)上面是当前分支的代码下面是远端进来的代码。这里要做的是根据需求手动判断保留哪个值或者综合改成合理的代码然后把、、这些标记全部删掉。修改完后执行# 标记冲突已解决 git add src/utils/userHelper.js # 继续执行 rebase 流程 git rebase --continuegit 会弹出 commit message 编辑界面默认沿用之前提交的信息直接保存退出即可。如果你在 rebase 过程中想中断放弃可以使用git rebase --abort回到 rebase 前的状态。我有一段时间对冲突合并分外的谨慎每次 rebase 之前都会复制一份当前分支到 tmp 分支相当于一个后悔药。3.4 推送被拒绝怎么办强推有风险操作需谨慎push 被拒是另一种高频问题一般表现为! [rejected] feature - feature (fetch first) error: failed to push some refs原因很简单远端有本地没有的提交。这时候很多人会偷懒直接git push -f强推。我必须强烈地说在共享分支上永远不要强推。强推会覆盖远端记录同事如果没及时拉取他们的本地提交就相当于“消失”了干掉的不是代码是信任。如果分支只有自己用比如某个纯私有功能分支强推问题不大可以放心。但多人共享分支正确做法就是上面 3.3 里的那套操作——先git pull --rebase origin 分支名处理冲突然后普通git push就能成功了。如果你发现自己不小心已经把强推干出去了并且影响到了同事赶紧跟同事同步情况让他们在了解冲突的前提下重新处理本地分支。这不是技术问题是沟通问题。4. 常见问题与排查技巧实录4.1 push 到一半网络中断、目标分支选错之类的问题有一种情况commit 成功了push 到一半却断网了导致远端其实没有完整收到你的提交。此时仓库状态比较暧昧常见的措辞是failed to push some refs。排查方式很直接# 查看本地和远端分支的差异 git status # 看到 ahead 状态就知道本地领先远端了 # 然后直接重新 push git push origin branch-namegit 的 push 操作设计成幂等的只要上次不是覆盖性操作force重新执行一下就好。别直接删本地分支也别急着大动作。另外还有一种常见的乌龙在main分支上直接改了代码想 push 到远端发现拒绝。我的建议是如果真的误改了 main 分支并且还没提交就直接git stash暂存起来切走在新分支 pop 出来继续干。git stash git checkout feature/another-branch git stash pop这一套下来代码安然无恙你也脱离了危险的 main 分支。4.2 想撤销刚才的 commitreset 和 revert 怎么选撤销提交也是高频操作。很多新手的习惯是直接git reset --hard这个是“时光倒流”的感觉直接把所有提交干掉危险度很高。硬重置会让你丢失所有未推送的本地修改和记录而且无法恢复除非你用了 reflog我不建议在任何场景随意使用硬重置。如果要撤销还没推送的 commit但想保留改动可以用软重置git reset --soft HEAD~1这会把 commit 撤销但保留你的代码改动在暂存区。相当于后悔了把东西退回到“已暂存”状态。git reset --mixed HEAD~1更常用一点撤销 commit 并把改动退回工作区需要重新 add这也是默认参数。如果 commit 已经 push 到远端了这时候别用 reset因为会跟远端历史冲突。正确的姿势是新增一个反向提交git revert HEADgit revert 会创建一个新提交内容是把上一个提交的改动翻转过来。这样既保留了原有历史又能让代码回到之前状态是协作场景里最安全的后悔药。4.3 .gitignore 不生效文件已经被跟踪了这个问题极高频而且踩坑的人特别多。你在.gitignore里写了node_modules/但 git status 还是能看到它。原因很可能是这个目录之前已经被纳入了版本控制.gitignore只对“未跟踪”的文件生效。解决方法是先把缓存里的文件移除跟踪git rm -r --cached node_modules/这条命令会保留磁盘文件只从 git 的跟踪列表里移除。之后 add 一下.gitignore和这个变更再 commit 一次你会发现那些大文件终于不再出现在 git status 里了。4.4 误删了分支怎么办 reflog 的救命用途这是几乎每个老手都会遇到的一次惊魂时刻。比如git branch -D feature/tmp然后发现这个分支上还有没合并的辛辛苦苦写的代码。一瞬间汗毛都竖起来了。别慌git 有一张“所有分支操作”的日志表叫 reflog。它是本地仓库的“时光机”。执行git reflog你会看到一串操作记录里面记录了每个分支 HEAD 曾经指向的 commit 哈希。找到你想恢复的那个 commit 哈希形如a1b2c3d然后git checkout -b feature/tmp-recovered a1b2c3d这个分支就复活了代码完好无损。我有个朋友真的靠这个方法在删错分支后救回了差不多两周的工作量。所以遇事不决先查 reflog这是本地仓库最后的底线。4.5 常见报错信息对照速查表报错信息特征核心原因推荐操作unable to read askpass response身份验证/凭据失效检查 SSH key 或 token重新认证Please commit or stash...切换分支时本地有未提交改动先 commit 或 stash 再切换分支You have unmerged paths合并/rebase 冲突未解决完逐个处理冲突并 add再继续 merge/rebasesrc refspec xxx does not match any本地分支名拼写错误git branch查看实际分支名再 pushfailed to push some refs远端有新提交推送被拒先 pull 再 push禁止无脑强推Not a git repository在非 git 目录执行了 git 命令检查当前目录是否为仓库根目录这张表标注了常见报错的特征、原因和解法建议收藏。我每次带新人的时候都要求他们把这张表贴在自己的笔记软件里遇到问题先对号入座。5. 进阶技巧与团队协作心得5.1 用别名简化高频命令操作熟练之后人就懒了。Git 命令其实有很多可以自定义的“快捷方式”叫别名alias。我对高频操作做了几个别名用了好多年效率极其显著git config --global alias.st status git config --global alias.cm commit git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg log --oneline --graph --all --decorate设置好之后这些别名永久生效。git lg看提交历史一屏就能看清所有分支的分叉走向非常好用我用完之后再也没用回原版 log。5.2 Commit 提交之后发现少了个文件很多人用完git commit后发现漏了个文件就赶紧又补一个 commit搞出两条记录。其实 git 有个“后悔药”选项可以把漏掉的内容追加到上一个 commit 里git add 漏掉的文件 git commit --amend --no-edit--amend表示修改上次提交--no-edit表示保留原始 commit message不会弹出编辑器。这个操作会把两次改动合并成一个 commit历史看起来依然干净。但是有一件事要牢牢记住--amend等同于重写上次提交如果上次提交已经 push 到远端那么本地和远端历史就不一致了。这种时候只有你自己在用的分支才推荐这么操作。公共分支上千万别用会引起一堆同步问题。5.3 如何写一封“有信息量”的 Pull Request 描述很多团队用 PR/MR 来合并代码。我看到过太多 PR 描述就是标题一句话点进去完全不知道改了什么、为什么要改、影响范围是什么、怎么测试。这等于把一个“代码变更”硬生生变成了“猜谜游戏”。我自己的习惯是写清楚四件事背景为什么有这次改动业务上或者技术上的原因是什么改动内容核心是哪些文件哪个模块大致思路是什么测试方式我验证了什么有没有跑单测手动验证了什么路径风险点哪些地方可能会影响现有功能需要重点 review 哪里这个习惯刚开始有点繁琐但坚持下来之后我发现团队里 review 代码的效率高了不止一个档次因为双方不需要反复沟通来猜测意图。5.4 分支命名与 commit 规范说一百遍都不嫌多关于团队协作中最大痛点我的体会是不是代码写得烂而是提交记录烂。一行“fix bug”看不出任何信息量等于没有提交信息。所以如果你是在一个团队里工作且你们还没有一套 git 规范我建议你主动牵头拟一份大致的骨架是分支命名feature/开头表示功能fix/开头表示修复docs/表示文档后面跟简要描述如feature/login-page-v2。commit message用上文提到的 Conventional Commits 格式type 必写scope 可写可不写subject 用祈使句不要超过 50 个字符左右。合并方式公共分支用 merge --no-ff保留合并记录个人分支随意。有了规范以后哪怕团队人很多git log翻出来依然是条理清晰的历史书这是团队“技术整洁度”的最直接体现。6. 实操心得从“会用”到“用好”很多人问我到底要怎么才能学好 git我的答案是忘掉命令大全去理解 git 的底层模型。你不需要背下所有命令的参数只需要知道你的“代码文件”目前处于四层状态中的哪一层然后选择把这一层推进到下一层的命令就行了。另外从心态上给大家一个建议git 操作没有“一锤子买卖”。所有危险操作几乎都有后悔药。reset有 reflog 护体rebase有abort兜底stash有pop恢复。所以不要因为怕出错就不敢操作越不敢操作技术就越生疏。哪怕真的一不小心删了分支只要没跑git gc清理垃圾对象基本都还能找回来。最后分享一个压箱底的习惯提交前花 30 秒审查一下git diff。很多人不看直接 add 全部结果把调试代码、console.log 全部发上去了后面处理起来非常尴尬。对这个场景我用的就是最原始的git diff看一眼改动是否符合预期再提交。这个习惯不仅帮你过滤低级失误还会慢慢提高你对代码变更的敏感度。真到了团队合作里别人看到你的 commit 永远干干净净这个信任感是无价的。git 传代码这件事说到底并不难难的是把每一步养成规范习惯。按照这篇文章的方法从下一次 commit 开始试着把 message 写清楚、把分支理干净、把流程走全。坚持一个月你会回来感谢自己。 
长河君 · 2026/10/18 23:03:56 · 阅读 1.2k Git代码提交实操指南：从工作区到远端仓库的完整流程与冲突处理
还在用“git 提交代码”把自己绕晕每次 pull、commit、push 的顺序都靠肌肉记忆遇到冲突就头皮发麻别急这篇文章把我自己从 “git 菜鸟” 到 “命令行操作如喝水” 的完整经验整理出来了。不管你是刚入行的新人还是被同事的“乱提交”折磨的队友这篇都能给你一套闭眼可用的标准操作流程。很多初学者甚至部分“熟练工”都觉得 git 难不是因为命令本身复杂而是脑子里没有一套完整的流程。今天我就把这套流程拆开了揉碎了讲从最基础的原理到最容易翻车的冲突解决再到几个我踩坑踩出来的小技巧一次性说清楚。1. 内容整体设计与思路拆解1.1 先搞清楚我们要解决什么问题git 传代码本质上就是解决一个问题如何安全、有序、不丢代码地把本地修改送到远端仓库。听起来简单但实际场景里你很可能遇到过这些情况提交完之后发现漏了一个文件结果又补了一次 commit历史记录里全是“fix typo”、“update”。push 的时候报错提示远端有更新你怕冲突直接强推把同事的代码覆盖了第二天被拉去开会。拉取代码的时候发现冲突不知道怎么处理一顿乱改不光没解决冲突还把不该删的代码删了。这些问题我一个一个都遇到过。后来我总结出一个核心理念git 操作不是靠背命令而是靠理解状态。你只要时刻清楚代码在本地仓库、暂存区、远端仓库这三个位置中的哪一步思路就清晰了。1.2 为什么强烈推荐“先拉再推”的标准动作对于团队协作而言顺序其实非常有讲究。最简单的原则就是“先更新、后提交、再推送”。很多人图省事习惯性直接 commit 然后 push结果远端已经被别人更新过了你的 push 就会被拒绝。被迫 merge 的时候又会引发一堆冲突。所以我个人的习惯是只要准备提交开头必然先git pull --rebase再 commit再 push。这一下就能避免绝大部分无谓的合并记录。当然rebase和merge的选择本身就有很多讲究后面我专门用一节来讲这里先不展开大家记住“先拉再推”这个总原则就行。1.3 核心逻辑工作区、暂存区、本地仓库的关系我一直在想用什么类比来解释 git 的状态最合适后来发现“存钱”这个例子最容易懂工作区Working Directory—— 你手里的现金随便花随便改只要没存进银行都算你自己的事。暂存区Index / Stage—— 你填好的存款单钱已经点了但还没交付到柜台也许你还会想再改改。本地仓库Local Repository—— 你的银行账户一旦 commit 进去这笔钱就有了交易流水不可随意抹除。远端仓库Remote Repository—— 你存进总行的账户其他同事其他分行才看得到、拿得到。理解了这四个概念git 传代码的流程就清晰了在工作区里改代码把要交的东西挑拣进暂存区在本地仓库生成一个不可回退的记录最后推送到远端让别人看见。是不是一下子就通透了2. 核心细节解析与实操要点2.1 初始化与配置别等出错了才想起配置身份很多时候我们拿到一台新电脑或者新项目第一件事就是git init。但你会发现即使你本地初始化成功第一次 commit 也会报错提示你配置 user.name 和 user.email。这是 git 的基本身份校验机制可别想着能跳过它会直接卡住你提交操作。我建议新手在安装完 git 后立刻执行这两条命令做全局配置git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个小细节值得注意--global是全局配置会影响这台电脑上所有仓库。如果你只希望在一个仓库里用特定身份比如公司项目和私人项目分开就在项目目录下执行不带--global的版本。配置完了可以用git config --list检查一下省得后面 push 的时候远端记录里挂着一个奇怪名字。2.2 精准暂存add 的三种境界git add是操作暂存区的命令但很多新手只知道git add .添加所有变更。不是不行而是不够好。直接添加全部文件很容易把调试用的临时文件、本地配置文件、甚至依赖包不小心加进来。这时候.gitignore文件的作用就出来了。我每次新建项目必写.gitignore把node_modules/、dist/、.env、*.log这些通通排除在版本管理之外。在暂存阶段我常用的命令有git add src/ # 添加某个目录 git add app.py # 添加某个文件 git add -p # 交互式逐块暂存非常精致git add -p是最容易被忽略的一个神级命令。它会把你的改动按“块”拆开让你挑选哪些改动需要被暂存哪些暂时不提交。比如你在一个文件里同时改了一个新功能和一行调试日志用-p就能只把功能代码提交上去把调试日志留在工作区。这个命令的熟练程度基本可以算是 git 操作的一个分水岭。2.3 提交的艺术写清楚 commit message 才算真正完成很多人都把 commit 当成“存个档”message 随便写个 “update” 甚至直接留空。说实话这对自己是省事了对同事和以后的自己就是灾难。你想想三个月后你看到一行git log满屏都是“update”你能记得当时改了啥吗我建议遵循业界常用的规范格式大致长这样type(scope): subject常见的 type 包括feat新功能、fix修 bug、docs文档、style格式、refactor重构、test测试等。scope 表示影响范围可以省略。举个例子git commit -m fix(login): 修复密码重置后无法登录的问题这样一行信息任何人都能一眼看懂这次提交做了什么。如果你觉得一行不够描述清楚可以不加-m直接执行git commitgit 会打开默认编辑器让你写多行详细描述。在团队里一份清晰的提交历史就是最好的项目文档。我还特别想提醒一点不要提交你还没有写完的代码。半成品代码提交上去如果同事 pull 下来跑不起来你的 commit 就成了“项目毒药”。宁可放在工作区或者单独的分支上也别打断团队主线。2.4 分支管理别在主分支上裸奔分支这块很多新手和老手的理解程度完全不同。新手完全不用分支一个 master 走天下push 全靠莽。真正经历过多人协作、代码被覆盖、频繁冲突的人才会明白分支就是 git 给你搭的“安全围栏”。我推荐一个稳定好用的“三贱客”分支模型main或master主分支长期存在且保持稳定只能通过合并分支进入不能直接在上面提交。develop开发分支大家日常的工作从这里拉出去分支再合并回来。feature/xxx功能分支比如feature/login-modal、feature/payment-api。你开发新功能就开一个开发完合并后就删掉。每次新开发前我都习惯在最新的develop基础上新建分支git checkout develop git pull origin develop git checkout -b feature/my-feature这样做的绝对好处是你在自己的开发流里为所欲为没人能干扰你。就算代码写崩了删掉这个分支重开一个就行完全不影响主干心理负担大大降低。3. 实操过程与核心环节实现3.1 最经典的完整提交流程演示下面这套流程是我在团队里推行的标准动作几乎适用于所有日常工作场景。我们来模拟一次完整的开发提交流程。假设我在feature/user-center分支上开发了一个用户中心的功能现在要提交代码# 1. 先看一眼当前仓库的状态心里有个底 git status # 2. 切换到自己的分支如果你是新建分支这步会带上 -b git checkout feature/user-center # 3. 把远端最新的代码拉到本地保持基线在同一水平线 git pull origin feature/user-center # 4. 将改动的文件加入暂存区 git add src/pages/user/ src/utils/userHelper.js # 5. 确认已经加入暂存区的文件情况 git status # 6. 提交到本地仓库凝视你的 commit message 三秒再确认 git commit -m feat(user): 新增用户中心个人信息展示与编辑功能 # 7. 推送前再拉一次远端代码防止有新的提交 git pull origin feature/user-center # 8. 推送本地提交到远端 git push origin feature/user-center流程跑完你的代码就安全抵达远端了。注意我在第 7 步又做了一次 pull这其实是双保险策略。很多人可能认为第 3 步已经拉过了没必要再拉一次但实际操作中有时候你第 3 步拉的版本和第 7 步之间的时间窗口里同事可能刚好 push 了内容。多拉一次总比后面处理 rebase 冲突要划算。我从第 3 步的pull多用的是git pull --rebase。上面说了--rebase和默认 merge 的差异很大这里我来补一段完整解释。3.2 深度解析pull 到底该用 merge 还是 rebase这是很多 git 教程里最含糊的一个点。git pull默认等价于git fetchgit merge。也就是说它会把远端的新提交直接合并到你的本地分支生成一个“合并提交”。这样的好处是记录真实缺点也很明显——提交历史会被搞得多叉分叉时间线变得像一团毛线。而git pull --rebase等价于git fetchgit rebase。它会把你本地尚未推送的提交“摘下来”接到远端最新的提交之后就像你的代码总是在最新代码之后修改的一样整个历史是一条干净直线。我个人的标准是在你的个人功能分支上用 rebase在公共的 develop/main 分支上用 merge。这样既保持了个人分支的整洁又避免在公共分支上重写提交历史导致其他同事的“操作历史”被更改。如果 pull 的过程中出现冲突rebase 的处理方式也稍微复杂一点不过别担心下面会专门讲。3.3 实战演示完整演示 rebase 下的冲突处理假设现在我在feature/user-center分支同事往develop分支提交了一个修改而且恰好改的是同一个文件。我的操作如下# 在 feature 分支执行 git pull origin develop --rebase执行之后git 会提示冲突CONFLICT (content): Merge conflict in src/utils/userHelper.js这时候不要慌。执行git status你会看到这个文件被标记为both modified。打开文件你大概率会看到这样的内容 HEAD const AGE_LIMIT 18; const AGE_LIMIT 21; develop (commit message)上面是当前分支的代码下面是远端进来的代码。这里要做的是根据需求手动判断保留哪个值或者综合改成合理的代码然后把、、这些标记全部删掉。修改完后执行# 标记冲突已解决 git add src/utils/userHelper.js # 继续执行 rebase 流程 git rebase --continuegit 会弹出 commit message 编辑界面默认沿用之前提交的信息直接保存退出即可。如果你在 rebase 过程中想中断放弃可以使用git rebase --abort回到 rebase 前的状态。我有一段时间对冲突合并分外的谨慎每次 rebase 之前都会复制一份当前分支到 tmp 分支相当于一个后悔药。3.4 推送被拒绝怎么办强推有风险操作需谨慎push 被拒是另一种高频问题一般表现为! [rejected] feature - feature (fetch first) error: failed to push some refs原因很简单远端有本地没有的提交。这时候很多人会偷懒直接git push -f强推。我必须强烈地说在共享分支上永远不要强推。强推会覆盖远端记录同事如果没及时拉取他们的本地提交就相当于“消失”了干掉的不是代码是信任。如果分支只有自己用比如某个纯私有功能分支强推问题不大可以放心。但多人共享分支正确做法就是上面 3.3 里的那套操作——先git pull --rebase origin 分支名处理冲突然后普通git push就能成功了。如果你发现自己不小心已经把强推干出去了并且影响到了同事赶紧跟同事同步情况让他们在了解冲突的前提下重新处理本地分支。这不是技术问题是沟通问题。4. 常见问题与排查技巧实录4.1 push 到一半网络中断、目标分支选错之类的问题有一种情况commit 成功了push 到一半却断网了导致远端其实没有完整收到你的提交。此时仓库状态比较暧昧常见的措辞是failed to push some refs。排查方式很直接# 查看本地和远端分支的差异 git status # 看到 ahead 状态就知道本地领先远端了 # 然后直接重新 push git push origin branch-namegit 的 push 操作设计成幂等的只要上次不是覆盖性操作force重新执行一下就好。别直接删本地分支也别急着大动作。另外还有一种常见的乌龙在main分支上直接改了代码想 push 到远端发现拒绝。我的建议是如果真的误改了 main 分支并且还没提交就直接git stash暂存起来切走在新分支 pop 出来继续干。git stash git checkout feature/another-branch git stash pop这一套下来代码安然无恙你也脱离了危险的 main 分支。4.2 想撤销刚才的 commitreset 和 revert 怎么选撤销提交也是高频操作。很多新手的习惯是直接git reset --hard这个是“时光倒流”的感觉直接把所有提交干掉危险度很高。硬重置会让你丢失所有未推送的本地修改和记录而且无法恢复除非你用了 reflog我不建议在任何场景随意使用硬重置。如果要撤销还没推送的 commit但想保留改动可以用软重置git reset --soft HEAD~1这会把 commit 撤销但保留你的代码改动在暂存区。相当于后悔了把东西退回到“已暂存”状态。git reset --mixed HEAD~1更常用一点撤销 commit 并把改动退回工作区需要重新 add这也是默认参数。如果 commit 已经 push 到远端了这时候别用 reset因为会跟远端历史冲突。正确的姿势是新增一个反向提交git revert HEADgit revert 会创建一个新提交内容是把上一个提交的改动翻转过来。这样既保留了原有历史又能让代码回到之前状态是协作场景里最安全的后悔药。4.3 .gitignore 不生效文件已经被跟踪了这个问题极高频而且踩坑的人特别多。你在.gitignore里写了node_modules/但 git status 还是能看到它。原因很可能是这个目录之前已经被纳入了版本控制.gitignore只对“未跟踪”的文件生效。解决方法是先把缓存里的文件移除跟踪git rm -r --cached node_modules/这条命令会保留磁盘文件只从 git 的跟踪列表里移除。之后 add 一下.gitignore和这个变更再 commit 一次你会发现那些大文件终于不再出现在 git status 里了。4.4 误删了分支怎么办 reflog 的救命用途这是几乎每个老手都会遇到的一次惊魂时刻。比如git branch -D feature/tmp然后发现这个分支上还有没合并的辛辛苦苦写的代码。一瞬间汗毛都竖起来了。别慌git 有一张“所有分支操作”的日志表叫 reflog。它是本地仓库的“时光机”。执行git reflog你会看到一串操作记录里面记录了每个分支 HEAD 曾经指向的 commit 哈希。找到你想恢复的那个 commit 哈希形如a1b2c3d然后git checkout -b feature/tmp-recovered a1b2c3d这个分支就复活了代码完好无损。我有个朋友真的靠这个方法在删错分支后救回了差不多两周的工作量。所以遇事不决先查 reflog这是本地仓库最后的底线。4.5 常见报错信息对照速查表报错信息特征核心原因推荐操作unable to read askpass response身份验证/凭据失效检查 SSH key 或 token重新认证Please commit or stash...切换分支时本地有未提交改动先 commit 或 stash 再切换分支You have unmerged paths合并/rebase 冲突未解决完逐个处理冲突并 add再继续 merge/rebasesrc refspec xxx does not match any本地分支名拼写错误git branch查看实际分支名再 pushfailed to push some refs远端有新提交推送被拒先 pull 再 push禁止无脑强推Not a git repository在非 git 目录执行了 git 命令检查当前目录是否为仓库根目录这张表标注了常见报错的特征、原因和解法建议收藏。我每次带新人的时候都要求他们把这张表贴在自己的笔记软件里遇到问题先对号入座。5. 进阶技巧与团队协作心得5.1 用别名简化高频命令操作熟练之后人就懒了。Git 命令其实有很多可以自定义的“快捷方式”叫别名alias。我对高频操作做了几个别名用了好多年效率极其显著git config --global alias.st status git config --global alias.cm commit git config --global alias.co checkout git config --global alias.br branch git config --global alias.lg log --oneline --graph --all --decorate设置好之后这些别名永久生效。git lg看提交历史一屏就能看清所有分支的分叉走向非常好用我用完之后再也没用回原版 log。5.2 Commit 提交之后发现少了个文件很多人用完git commit后发现漏了个文件就赶紧又补一个 commit搞出两条记录。其实 git 有个“后悔药”选项可以把漏掉的内容追加到上一个 commit 里git add 漏掉的文件 git commit --amend --no-edit--amend表示修改上次提交--no-edit表示保留原始 commit message不会弹出编辑器。这个操作会把两次改动合并成一个 commit历史看起来依然干净。但是有一件事要牢牢记住--amend等同于重写上次提交如果上次提交已经 push 到远端那么本地和远端历史就不一致了。这种时候只有你自己在用的分支才推荐这么操作。公共分支上千万别用会引起一堆同步问题。5.3 如何写一封“有信息量”的 Pull Request 描述很多团队用 PR/MR 来合并代码。我看到过太多 PR 描述就是标题一句话点进去完全不知道改了什么、为什么要改、影响范围是什么、怎么测试。这等于把一个“代码变更”硬生生变成了“猜谜游戏”。我自己的习惯是写清楚四件事背景为什么有这次改动业务上或者技术上的原因是什么改动内容核心是哪些文件哪个模块大致思路是什么测试方式我验证了什么有没有跑单测手动验证了什么路径风险点哪些地方可能会影响现有功能需要重点 review 哪里这个习惯刚开始有点繁琐但坚持下来之后我发现团队里 review 代码的效率高了不止一个档次因为双方不需要反复沟通来猜测意图。5.4 分支命名与 commit 规范说一百遍都不嫌多关于团队协作中最大痛点我的体会是不是代码写得烂而是提交记录烂。一行“fix bug”看不出任何信息量等于没有提交信息。所以如果你是在一个团队里工作且你们还没有一套 git 规范我建议你主动牵头拟一份大致的骨架是分支命名feature/开头表示功能fix/开头表示修复docs/表示文档后面跟简要描述如feature/login-page-v2。commit message用上文提到的 Conventional Commits 格式type 必写scope 可写可不写subject 用祈使句不要超过 50 个字符左右。合并方式公共分支用 merge --no-ff保留合并记录个人分支随意。有了规范以后哪怕团队人很多git log翻出来依然是条理清晰的历史书这是团队“技术整洁度”的最直接体现。6. 实操心得从“会用”到“用好”很多人问我到底要怎么才能学好 git我的答案是忘掉命令大全去理解 git 的底层模型。你不需要背下所有命令的参数只需要知道你的“代码文件”目前处于四层状态中的哪一层然后选择把这一层推进到下一层的命令就行了。另外从心态上给大家一个建议git 操作没有“一锤子买卖”。所有危险操作几乎都有后悔药。reset有 reflog 护体rebase有abort兜底stash有pop恢复。所以不要因为怕出错就不敢操作越不敢操作技术就越生疏。哪怕真的一不小心删了分支只要没跑git gc清理垃圾对象基本都还能找回来。最后分享一个压箱底的习惯提交前花 30 秒审查一下git diff。很多人不看直接 add 全部结果把调试代码、console.log 全部发上去了后面处理起来非常尴尬。对这个场景我用的就是最原始的git diff看一眼改动是否符合预期再提交。这个习惯不仅帮你过滤低级失误还会慢慢提高你对代码变更的敏感度。真到了团队合作里别人看到你的 commit 永远干干净净这个信任感是无价的。git 传代码这件事说到底并不难难的是把每一步养成规范习惯。按照这篇文章的方法从下一次 commit 开始试着把 message 写清楚、把分支理干净、把流程走全。坚持一个月你会回来感谢自己。