Git 这个东西说难不难说简单也真不简单。我见过不少人把add和commit背得滚瓜烂熟可是一遇到分支合并、代码冲突、提交撤销就手足无措最后只能靠复制粘贴网上的命令来救急运气好没事运气差直接把同事的代码搞没。其实 Git 的常用操作命令就那二十来条关键不是死记硬背而是理解它们背后那套三板斧式的数据模型。你只要搞清楚工作区、暂存区、版本库三个状态是怎么流转的再配合几条高频命令日常开发 95% 的场景都能稳稳拿捏。这篇内容适合刚接触 Git 的新手也适合已经写了一年半年代码、但对某些命令只会照抄用法的开发者。我会把命令分成状态查看、日常提交、分支合并、远程协作、撤销恢复、问题排查六个维度来讲每个命令都告诉你它解决什么问题、什么时候用、有哪些坑。全程没有任何学术腔全是实战时踩过坑之后整理出来的要点希望你看完能建立一套自己的 Git 操作套路而不是继续当命令搬运工。1. 想用好 Git先搞清楚这棵树是怎么长的1.1 工作区、暂存区、版本库到底在说什么很多人第一次学 Git 就被三个概念搞晕工作区Working Directory、暂存区Index / Staging Area、版本库Repository。我用一句话帮你记住它们的分工工作区是你眼睛看到的文件暂存区是你要打包进快照的购物车版本库是已经封箱入库的货物。你写代码时修改的是工作区文件git add把修改内容放进暂存区git commit把暂存区内容固化成一次提交写入版本库。这个过程很像一个物流仓库——货物先放到暂存架上待验验完才入正式库存。理解了这一点后面所有命令都变得顺理成章git status是检查当前各区域的状态git diff是对比不同区域之间的差异git restore则是把某个区域的内容回滚到另一个区域的状态。新手最容易犯的错误就是在git add之后发现改错了然后到处找撤销 add的命令。其实根本不用焦虑暂存区只是准备区改错了随时可以重新add覆盖或者用git restore --staged把暂存区内容退回工作区。只要你清楚每个命令动的是哪个区域就不会越操作越乱。1.2 提交、分支、HEAD 三者的关系版本库里的每一次提交commit都是一个不可变的快照包含作者、时间、提交信息和一串唯一的哈希值。分支branch本质上只是一个指向某个提交的可移动指针而 HEAD 则是你当前站在哪里的指针通常指向某个分支的最新提交。这种设计带来一个很重要的推论你切换分支时Git 做的事情只是移动 HEAD 指针、并同步更新工作区文件。它并不是把代码复制来复制去。所以分支切换非常轻量这也是为什么 Git 鼓励多建分支、频繁合并——创建分支的开销几乎可以忽略不计大胆开分支不会把仓库搞爆炸。日常工作中我见过很多人不敢用分支总觉得自己代码还没写完冒然切分支会把半成品弄丢。这种担心其实多余。只要你的工作区改动没有冲突git switch会帮你带上改动如果确实有冲突风险Git 会明确报错阻止你切换绝不会偷偷丢文件。我在后面第 5 节会专门讲git stash那就是为没写完就想切分支这种场景准备的。2. 日常开发高频命令实操先把手感练出来2.1 状态三件套status、log、diffgit status是我使用频率最高的命令没有之一。我建议你每次敲别的 Git 命令之前先敲一次git status看清楚当前站在哪个分支、哪些文件被改过、哪些已经进入暂存区。很多时候你以为自己在 A 分支实际却在 B 分支一个status就能当场揭穿。git log用来查看提交历史。裸的log输出信息太多太挤我实际使用中几乎总是配合参数git log --oneline只看一行摘要git log --graph --oneline --all查看所有分支的网状关系git log -p查看每次提交的具体改动内容git log --author用户名筛选某个人的提交。查最近几条提交用git log -3查某个文件的变更历史用git log -- 文件名。这些参数不用全记用到时能想起来log 有这个能力就行。git diff是精确到行的差异查看器。git diff比较工作区和暂存区git diff --staged或--cached比较暂存区和上一次提交git diff HEAD则比较工作区全部改动和最后一次提交的差距。排 bug 时我经常用git diff快速确认这次到底改了什么尤其是在多个文件混改的情况下比肉眼翻代码靠谱得多。2.2 提交动作的标准姿势add、commitgit add可以接单个文件、多个文件、整个目录也可以用.把所有改动加入暂存区。我看到不少初学者一上来就git add . git commit -m update这种做法很容易把临时文件、调试日志、敏感配置一起提交上去。更稳的做法是git add时明确指定文件或者先用git status扫一眼再决定。养成看清楚再 add的习惯能避免很多社死现场。如果想要更精细地控制提交内容可以使用git add -ppatch 模式它会把一个文件内的不同改动逐块展示让你选择哪些块加入暂存区、哪些块暂不加入。一个文件里同时修改了两处不相关的功能时这个功能非常好用可以让每次提交保持逻辑单一。git commit提交时需要注意两点。一是提交信息要写清楚为什么改而不是改了什么比如fix: 修复登录接口在空密码时返回 500就比update强得多。二是一次commit只做一件事别把修 bug和重构代码混在一个提交里否则以后git log回溯时你会非常痛苦。如果提交后发现漏了一个小改动不想为此新增一条提交记录可以用git commit --amend把当前暂存区的改动合并进上一次提交注意这种方式会改写提交历史已经推送到远程并且他人拉取过的分支要谨慎使用。2.3 分支管理基本功branch、switch、checkoutgit branch查看本地分支列表当前分支前面会有一个星号。git branch 新分支名基于当前 HEAD 创建新分支git branch -d 分支名删除已合并的分支如果分支还没合并又想强删用-D但要先确认里面的提交真的不要了。切换分支我主推git switch而不是老牌的git checkout。git switch -c 新分支名表示创建并切换两步合并成一步。git checkout因为身兼切分支和还原文件两个职责新手很容易误用——比如git checkout .会把工作区所有未提交的改动直接丢弃我还真见过有人手滑执行完当场崩溃。相比之下git switch只管切换分支语义清晰更不容易出事故。在实操中我还会用到git worktree add它可以让你同一仓库同时检出多个分支到不同目录。场景是你在 A 分支开发到一半B 分支线上出了紧急 bug 要立刻修但不想 stash 打断思路。开一个 worktree 到另一个目录互不干扰。这属于进阶操作但确实好用建议了解。3. 分支合并与冲突处理把最头疼的部分讲透3.1 合并前的准备工作合并之前先确认两件事当前所在分支是否正确、工作区/暂存区是否干净。用git status检查如果有未提交的改动最好先git commit或者git stash避免合并过程中产生混乱。我犯过的错误是没提交就在分支上执行 merge结果 Git 提示本地改动会被覆盖直接拒绝合并虽然安全但那一刻有点手足无措。git merge有两种常见结果。快进合并Fast-forward发生在目标分支没有新的提交、当前分支可以直接指针前移时历史会呈现一条直线。非快进合并Three-way merge发生在两个分支都有各自新提交时Git 会生成一个额外的合并提交历史呈现分叉后再汇合。如果希望保留分叉痕迹、明确记录这里有过一次合并可以加--no-ff强制生成合并提交反过来说后台维护型项目为了历史清爽可能会刻意用--ff-only拒绝创建合并提交。3.2 冲突产生的原理与解决步骤冲突的本质是两个分支修改了同一处代码Git 无法自动判断该保留谁只能交给人类裁决。看到CONFLICT (content)字样不要慌这不是天塌了只是 Git 在向你汇报这块代码需要你拿主意。解决冲突的标准流程是先用git status找出冲突文件状态为 Unmerged打开这些文件里面会出现类似下面的标记 HEAD 这里是当前分支的内容 这里是合并进来的分支的内容 feature/login你要做的是把矛盾区域改成最终想要的样子然后删掉、、这三行标记。改完后执行git add把该文件标记为已解决全部解决完再执行git merge --continue在旧版本可能需要直接git commit一个解除冲突的合并提交就诞生了。这里有个非常实用的建议解决冲突时不要只盯着自己写的代码一定要花十秒钟想想对方为什么这么改。实战中很多冲突根因是双方都改了同名的工具函数这时合并不是简单的二选一而是理解两边需求后做一个兼容双方对共识实现。如果修改文件的逻辑较大宁可把同事拉来当面沟通也不要自己拍板写完就提交。3.3 merge 还是 rebase怎么选git rebase和 merge 的目标都是整合分支但思路截然不同。merge 保留分叉让历史忠实rebase 则是把你这条分支上的提交一个个重放到目标分支的顶端让历史变成一条干净的直线。视觉上rebase 后的 log 非常清爽代价是改写提交哈希一旦分支已经被别人拉取强制 rebase 会导致对端历史错乱。我的选择原则是本地分支还没推送远程、或者只有自己在开发的分支放心用 rebase 整理历史已经推送远程并且多人共用的分支只用 merge绝不用 rebase 强行改写历史。场景上从主分支同步最新代码到自己的功能分支时git pull --rebase比git pull更常用因为它避免了大量无意义的merge main into feature提交。执行 rebase 时同样可能遇到冲突解决方式跟 merge 冲突基本一致改文件、git add、然后git rebase --continue。如果 rebase 越整越乱想放弃当前操作回到 rebase 之前的状态用git rebase --abort它会把你安全送回起点这一点比手动重置省心太多。4. 远程仓库协作clone、remote、fetch、pull、push4.1 一次完整的远程协作流程git clone是把远程仓库完整复制到本地包含所有分支的引用和完整历史。注意clone之后默认你只在默认分支上工作其他远程分支要在需要时用git switch 分支名或git checkout --track建立本地跟踪分支。对于已经存在本地仓库、需要关联远程的情况用git remote add origin 仓库地址。git remote -v可以查看当前配置的远程地址。一个仓库可以配多个远程分别命名为 origin、upstream 等这对于 Fork 协作很关键——origin 指向你自己的副本upstream 指向上游原仓库需要同步上游更新时git fetch upstream。首次推送本地分支到远程标准命令是git push -u origin main。其中-u是--set-upstream的缩写作用是建立本地分支和远程分支的跟踪关系。建立之后后续直接敲git push或git pull就能自动匹配对应的远程分支不用每次都带全参数。4.2 fetch 和 pull 的区别别再混着用了git fetch只把远程的最新提交和分支信息下载到本地不动你当前的工作区。git pull则是git fetch加上git merge的合体直接试图把远程分支合并进当前分支。理解这个区别很重要。很多人习惯一上来就git pull但 pull 实质上有合并动作如果你的本地有未提交的改动且与远程改动冲突pull 会直接失败报错。稳妥的流程是先git fetch看看远程发生了什么再决定是 merge 还是 rebase最后才考虑真正合并。尤其是参与多人协作项目时fetch diff pull三步走能让你对每一次远端变化心里有底而不是被 pull 的不确定性牵着鼻子走。4.3 远程分支的同步与清理git push时如果远程分支被别人先推了新提交你的推送会被拒绝提示non-fast-forward。这时不要莽撞加--force强推因为强推会覆盖他人的工作属于高危操作。正确做法是先git pull --rebase拉取最新代码解决冲突后再推送。如果确实需要强推比如你刚推送的提交发现有敏感信息需要改写用git push --force-with-lease会比裸--force安全很多它会在强推前检查远程分支是否被你最近获取过的状态之外的新提交改动多一层保护。清理远程分支方面合并完的功能分支可以用git push origin --delete 分支名删除远程分支本地分支用git branch -d 分支名删除。本地仓库里还留着远程已经删除的分支引用可执行git fetch --prune或git remote prune origin清理。这个操作建议定期做否则本地积累一堆幽灵分支引用看 log 时会非常困惑。5. 撤销与恢复命令大盘点改错了有救5.1 工作区改乱了restore 和 checkout撤销没有add过、仅存在于工作区的改动最简单的是git restore 文件名等价于老命令git checkout -- 文件名。如果你想把某个文件恢复到某个历史提交的状态用git restore --source提交哈希 文件名。注意这类操作是不可逆的执行前确认那个文件里没有你想留的修改建议先git diff看一眼再动手。如果改动已经add进了暂存区但还没提交想退回工作区使用git restore --staged 文件名这只会让文件状态从暂存区移除不会动文件内容。你可能会发现学会这一条后之前网上那些git rm --cached的偏方基本用不上了。另外git rm有它自己的用途但撤销 add不是其中一个。5.2 已经提交了reset 还是 revert提交后发现写错了你有两条路git reset和git revert。区别核心在于reset 是移动当前分支指针、相当于回退时间线revert 是生成一个新的反向提交、相当于用一次新提交抵消旧改动。git reset有三个常用级别。--soft只移动 HEAD 回到目标提交改动全部留在暂存区--mixed默认把改动退回工作区--hard直接丢弃所有改动工作区、暂存区、分支指针全部回到目标提交状态。--hard是条单行道执行前必须确认最好git log记下当前提交哈希万一后悔还能用git reset --hard 原哈希找回。git revert不修改已有提交历史更适合已经推送到远程的分支。比如你发布了 v1.2 之后发现某个功能有 bug用git revert 提交哈希生成一个相反提交把该功能去掉历史里会清楚记录这次撤销。多提交连撤可以用git revert 旧提交..新提交。在多人协作分支上我几乎只用 revert 不用 reset因为它不会给同事造成历史错乱合作起来更文明。5.3 半路想切分支stash 优雅暂存现场开发到一半突然要切分支去改热修复但改动不想丢弃也不想提交。git stash会把你工作区的改动存到一个临时栈中让工作区恢复干净。之后切分支、该干嘛干嘛事后再回到这个分支执行git stash pop改动就会弹回来如同从未离开。git stash list查看暂存列表我可以为你恢复指定一条git stash apply stash{1}。apply不会删除栈中的记录pop会弹出并删除。如果 stash 后你的工作区因为后续改动而冲突pop会报冲突但 stash 记录还在解决冲突后git stash drop手动清理就行。我用 stash 还有一个高级习惯git stash push -m 描述信息给每次暂存写个标签。因为 stash 默认只显示WIP on branch: 哈希值过几天再看根本想不起当时存的是什么加上描述后辨识度立即提升。如果你并不少会感谢这个习惯的。另外现在 Git 2.23 提供了git switch的邻居git restore以及git stash push都是为了把各种多语义命令做拆分让操作更安全清晰。新学 Git 的同学建议直接养成这个新式命令习惯老同学想改也不难。6. 常见问题排查速查表直接翻答案6.1 分离头指针Detached HEAD状态当你git checkout 某个提交哈希而不是分支名时HEAD 不指向任何分支进入 Detached HEAD。这个状态下新提交不会属于任何分支一旦切走很容易丢失。如果确实需要在某个历史提交上做改动先git switch -c 新分支名基于当前状态创建分支再接续开发。如果只是想看看代码什么都不改、直接切走即可。6.2 提交提交错了分支把功能提交到了 main而不是 feature/login。别慌先记下那个提交的哈希执行git switch feature/login然后git cherry-pick 哈希把这个提交复制到当前分支。回到 main 后如果该提交是最近一次且还没推送git reset --hard HEAD~1把它从 main 移除如果已经推送到远程就用git revert生成反向提交。整个过程其实比很多人想象中简单关键是动手前先想清楚分支指针的移动路径。6.3 合并冲突进行到一半想放弃内容冲突甚至文件冲突比如两边都改动了同一个二进制文件名导致合并卡住时可以用git merge --abort回到合并前状态。这个命令在 rebase 场景对应git rebase --abort。切记先保存你手动改过的中间内容否则 abort 之后那些半成品也会一起消失。6.4 持续提示输入用户名密码以前遇到这类问题通常靠 credential helper 配置解决而 2021 年后很多平台不再支持账号密码直接 push推荐使用 SSH key 或 token 方式认证。如果git push反复失败或要求输入口令先用ssh -T git平台域名以实际平台为准诊断 SSH 是否连通再检查本地仓库的 remote 地址用的 HTTPS 还是 SSHgit remote set-url origin可以随时切换地址格式。日常建议用 SSH 认证配置一次长期省心。6.5 误把大文件提交进仓库Git 对仓库大小非常敏感一旦提交了类似编译产物的大型二进制到历史记录中即使之后删掉文件这个膨胀仍会留在 .git 历史里。若提交还未推送用重置或 amend 都行若已推送且历史较深需要工具重写历史这一操作复杂且会改写全部提交哈希。更根本的预防方案是把不需要跟踪的文件放进.gitignore例如node_modules/ dist/ *.log .DS_Store.gitignore是每个仓库第一件应该做好的事。下面我把高频遇到的问题整理成一张对照表方便你直接查阅症状成因推荐命令工作区改乱了想还原未 add 的修改git restore 文件名add 多了想退出来暂存区内容不需要git restore --staged 文件名提交信息打错了提交未推送或仅本地git commit --amend最近一次提交想撤销未推送提交到错误分支git reset --soft HEAD~1已推送的提交想撤销公共历史不能改写git revert 提交哈希切换分支但想保留现场工作区未提交改动git stash push -m 描述合并冲突想放弃中间状态太乱git merge --abort推送到远程被拒绝远程有新提交git pull --rebase后重推查找某行代码是谁改的定位回归来源git blame 文件名每张表其实都浓缩了一个完整场景的前因后果。我把这个表做成了一张实体便签贴在显示器旁边前几周频繁翻之后基本不看了因为反复几次肌肉记忆自动形成。你也可以试试这个土办法。我个人在实际操作中的体会是Git 命令学的不是数量是模型。你不需要背下所有参数只需要清楚地知道工作区、暂存区、版本库、远程这四个层级再想清楚每条命令在这四层之间搬运了什么内容、移动了什么指针就不会在出现冲突或误操作时手忙脚乱。后面我每次换新环境第一件事就是把.gitignore写好把默认提交信息规范用文本存到本地配置文件里避免临时拼凑。建议你也找一个小项目按这篇文章的流程从头到尾练两遍分支和远程操作把害怕冲突变成预判冲突那种感觉会很不一样。
Git 这个东西说难不难说简单也真不简单。我见过不少人把add和commit背得滚瓜烂熟可是一遇到分支合并、代码冲突、提交撤销就手足无措最后只能靠复制粘贴网上的命令来救急运气好没事运气差直接把同事的代码搞没。其实 Git 的常用操作命令就那二十来条关键不是死记硬背而是理解它们背后那套三板斧式的数据模型。你只要搞清楚工作区、暂存区、版本库三个状态是怎么流转的再配合几条高频命令日常开发 95% 的场景都能稳稳拿捏。这篇内容适合刚接触 Git 的新手也适合已经写了一年半年代码、但对某些命令只会照抄用法的开发者。我会把命令分成状态查看、日常提交、分支合并、远程协作、撤销恢复、问题排查六个维度来讲每个命令都告诉你它解决什么问题、什么时候用、有哪些坑。全程没有任何学术腔全是实战时踩过坑之后整理出来的要点希望你看完能建立一套自己的 Git 操作套路而不是继续当命令搬运工。1. 想用好 Git先搞清楚这棵树是怎么长的1.1 工作区、暂存区、版本库到底在说什么很多人第一次学 Git 就被三个概念搞晕工作区Working Directory、暂存区Index / Staging Area、版本库Repository。我用一句话帮你记住它们的分工工作区是你眼睛看到的文件暂存区是你要打包进快照的购物车版本库是已经封箱入库的货物。你写代码时修改的是工作区文件git add把修改内容放进暂存区git commit把暂存区内容固化成一次提交写入版本库。这个过程很像一个物流仓库——货物先放到暂存架上待验验完才入正式库存。理解了这一点后面所有命令都变得顺理成章git status是检查当前各区域的状态git diff是对比不同区域之间的差异git restore则是把某个区域的内容回滚到另一个区域的状态。新手最容易犯的错误就是在git add之后发现改错了然后到处找撤销 add的命令。其实根本不用焦虑暂存区只是准备区改错了随时可以重新add覆盖或者用git restore --staged把暂存区内容退回工作区。只要你清楚每个命令动的是哪个区域就不会越操作越乱。1.2 提交、分支、HEAD 三者的关系版本库里的每一次提交commit都是一个不可变的快照包含作者、时间、提交信息和一串唯一的哈希值。分支branch本质上只是一个指向某个提交的可移动指针而 HEAD 则是你当前站在哪里的指针通常指向某个分支的最新提交。这种设计带来一个很重要的推论你切换分支时Git 做的事情只是移动 HEAD 指针、并同步更新工作区文件。它并不是把代码复制来复制去。所以分支切换非常轻量这也是为什么 Git 鼓励多建分支、频繁合并——创建分支的开销几乎可以忽略不计大胆开分支不会把仓库搞爆炸。日常工作中我见过很多人不敢用分支总觉得自己代码还没写完冒然切分支会把半成品弄丢。这种担心其实多余。只要你的工作区改动没有冲突git switch会帮你带上改动如果确实有冲突风险Git 会明确报错阻止你切换绝不会偷偷丢文件。我在后面第 5 节会专门讲git stash那就是为没写完就想切分支这种场景准备的。2. 日常开发高频命令实操先把手感练出来2.1 状态三件套status、log、diffgit status是我使用频率最高的命令没有之一。我建议你每次敲别的 Git 命令之前先敲一次git status看清楚当前站在哪个分支、哪些文件被改过、哪些已经进入暂存区。很多时候你以为自己在 A 分支实际却在 B 分支一个status就能当场揭穿。git log用来查看提交历史。裸的log输出信息太多太挤我实际使用中几乎总是配合参数git log --oneline只看一行摘要git log --graph --oneline --all查看所有分支的网状关系git log -p查看每次提交的具体改动内容git log --author用户名筛选某个人的提交。查最近几条提交用git log -3查某个文件的变更历史用git log -- 文件名。这些参数不用全记用到时能想起来log 有这个能力就行。git diff是精确到行的差异查看器。git diff比较工作区和暂存区git diff --staged或--cached比较暂存区和上一次提交git diff HEAD则比较工作区全部改动和最后一次提交的差距。排 bug 时我经常用git diff快速确认这次到底改了什么尤其是在多个文件混改的情况下比肉眼翻代码靠谱得多。2.2 提交动作的标准姿势add、commitgit add可以接单个文件、多个文件、整个目录也可以用.把所有改动加入暂存区。我看到不少初学者一上来就git add . git commit -m update这种做法很容易把临时文件、调试日志、敏感配置一起提交上去。更稳的做法是git add时明确指定文件或者先用git status扫一眼再决定。养成看清楚再 add的习惯能避免很多社死现场。如果想要更精细地控制提交内容可以使用git add -ppatch 模式它会把一个文件内的不同改动逐块展示让你选择哪些块加入暂存区、哪些块暂不加入。一个文件里同时修改了两处不相关的功能时这个功能非常好用可以让每次提交保持逻辑单一。git commit提交时需要注意两点。一是提交信息要写清楚为什么改而不是改了什么比如fix: 修复登录接口在空密码时返回 500就比update强得多。二是一次commit只做一件事别把修 bug和重构代码混在一个提交里否则以后git log回溯时你会非常痛苦。如果提交后发现漏了一个小改动不想为此新增一条提交记录可以用git commit --amend把当前暂存区的改动合并进上一次提交注意这种方式会改写提交历史已经推送到远程并且他人拉取过的分支要谨慎使用。2.3 分支管理基本功branch、switch、checkoutgit branch查看本地分支列表当前分支前面会有一个星号。git branch 新分支名基于当前 HEAD 创建新分支git branch -d 分支名删除已合并的分支如果分支还没合并又想强删用-D但要先确认里面的提交真的不要了。切换分支我主推git switch而不是老牌的git checkout。git switch -c 新分支名表示创建并切换两步合并成一步。git checkout因为身兼切分支和还原文件两个职责新手很容易误用——比如git checkout .会把工作区所有未提交的改动直接丢弃我还真见过有人手滑执行完当场崩溃。相比之下git switch只管切换分支语义清晰更不容易出事故。在实操中我还会用到git worktree add它可以让你同一仓库同时检出多个分支到不同目录。场景是你在 A 分支开发到一半B 分支线上出了紧急 bug 要立刻修但不想 stash 打断思路。开一个 worktree 到另一个目录互不干扰。这属于进阶操作但确实好用建议了解。3. 分支合并与冲突处理把最头疼的部分讲透3.1 合并前的准备工作合并之前先确认两件事当前所在分支是否正确、工作区/暂存区是否干净。用git status检查如果有未提交的改动最好先git commit或者git stash避免合并过程中产生混乱。我犯过的错误是没提交就在分支上执行 merge结果 Git 提示本地改动会被覆盖直接拒绝合并虽然安全但那一刻有点手足无措。git merge有两种常见结果。快进合并Fast-forward发生在目标分支没有新的提交、当前分支可以直接指针前移时历史会呈现一条直线。非快进合并Three-way merge发生在两个分支都有各自新提交时Git 会生成一个额外的合并提交历史呈现分叉后再汇合。如果希望保留分叉痕迹、明确记录这里有过一次合并可以加--no-ff强制生成合并提交反过来说后台维护型项目为了历史清爽可能会刻意用--ff-only拒绝创建合并提交。3.2 冲突产生的原理与解决步骤冲突的本质是两个分支修改了同一处代码Git 无法自动判断该保留谁只能交给人类裁决。看到CONFLICT (content)字样不要慌这不是天塌了只是 Git 在向你汇报这块代码需要你拿主意。解决冲突的标准流程是先用git status找出冲突文件状态为 Unmerged打开这些文件里面会出现类似下面的标记 HEAD 这里是当前分支的内容 这里是合并进来的分支的内容 feature/login你要做的是把矛盾区域改成最终想要的样子然后删掉、、这三行标记。改完后执行git add把该文件标记为已解决全部解决完再执行git merge --continue在旧版本可能需要直接git commit一个解除冲突的合并提交就诞生了。这里有个非常实用的建议解决冲突时不要只盯着自己写的代码一定要花十秒钟想想对方为什么这么改。实战中很多冲突根因是双方都改了同名的工具函数这时合并不是简单的二选一而是理解两边需求后做一个兼容双方对共识实现。如果修改文件的逻辑较大宁可把同事拉来当面沟通也不要自己拍板写完就提交。3.3 merge 还是 rebase怎么选git rebase和 merge 的目标都是整合分支但思路截然不同。merge 保留分叉让历史忠实rebase 则是把你这条分支上的提交一个个重放到目标分支的顶端让历史变成一条干净的直线。视觉上rebase 后的 log 非常清爽代价是改写提交哈希一旦分支已经被别人拉取强制 rebase 会导致对端历史错乱。我的选择原则是本地分支还没推送远程、或者只有自己在开发的分支放心用 rebase 整理历史已经推送远程并且多人共用的分支只用 merge绝不用 rebase 强行改写历史。场景上从主分支同步最新代码到自己的功能分支时git pull --rebase比git pull更常用因为它避免了大量无意义的merge main into feature提交。执行 rebase 时同样可能遇到冲突解决方式跟 merge 冲突基本一致改文件、git add、然后git rebase --continue。如果 rebase 越整越乱想放弃当前操作回到 rebase 之前的状态用git rebase --abort它会把你安全送回起点这一点比手动重置省心太多。4. 远程仓库协作clone、remote、fetch、pull、push4.1 一次完整的远程协作流程git clone是把远程仓库完整复制到本地包含所有分支的引用和完整历史。注意clone之后默认你只在默认分支上工作其他远程分支要在需要时用git switch 分支名或git checkout --track建立本地跟踪分支。对于已经存在本地仓库、需要关联远程的情况用git remote add origin 仓库地址。git remote -v可以查看当前配置的远程地址。一个仓库可以配多个远程分别命名为 origin、upstream 等这对于 Fork 协作很关键——origin 指向你自己的副本upstream 指向上游原仓库需要同步上游更新时git fetch upstream。首次推送本地分支到远程标准命令是git push -u origin main。其中-u是--set-upstream的缩写作用是建立本地分支和远程分支的跟踪关系。建立之后后续直接敲git push或git pull就能自动匹配对应的远程分支不用每次都带全参数。4.2 fetch 和 pull 的区别别再混着用了git fetch只把远程的最新提交和分支信息下载到本地不动你当前的工作区。git pull则是git fetch加上git merge的合体直接试图把远程分支合并进当前分支。理解这个区别很重要。很多人习惯一上来就git pull但 pull 实质上有合并动作如果你的本地有未提交的改动且与远程改动冲突pull 会直接失败报错。稳妥的流程是先git fetch看看远程发生了什么再决定是 merge 还是 rebase最后才考虑真正合并。尤其是参与多人协作项目时fetch diff pull三步走能让你对每一次远端变化心里有底而不是被 pull 的不确定性牵着鼻子走。4.3 远程分支的同步与清理git push时如果远程分支被别人先推了新提交你的推送会被拒绝提示non-fast-forward。这时不要莽撞加--force强推因为强推会覆盖他人的工作属于高危操作。正确做法是先git pull --rebase拉取最新代码解决冲突后再推送。如果确实需要强推比如你刚推送的提交发现有敏感信息需要改写用git push --force-with-lease会比裸--force安全很多它会在强推前检查远程分支是否被你最近获取过的状态之外的新提交改动多一层保护。清理远程分支方面合并完的功能分支可以用git push origin --delete 分支名删除远程分支本地分支用git branch -d 分支名删除。本地仓库里还留着远程已经删除的分支引用可执行git fetch --prune或git remote prune origin清理。这个操作建议定期做否则本地积累一堆幽灵分支引用看 log 时会非常困惑。5. 撤销与恢复命令大盘点改错了有救5.1 工作区改乱了restore 和 checkout撤销没有add过、仅存在于工作区的改动最简单的是git restore 文件名等价于老命令git checkout -- 文件名。如果你想把某个文件恢复到某个历史提交的状态用git restore --source提交哈希 文件名。注意这类操作是不可逆的执行前确认那个文件里没有你想留的修改建议先git diff看一眼再动手。如果改动已经add进了暂存区但还没提交想退回工作区使用git restore --staged 文件名这只会让文件状态从暂存区移除不会动文件内容。你可能会发现学会这一条后之前网上那些git rm --cached的偏方基本用不上了。另外git rm有它自己的用途但撤销 add不是其中一个。5.2 已经提交了reset 还是 revert提交后发现写错了你有两条路git reset和git revert。区别核心在于reset 是移动当前分支指针、相当于回退时间线revert 是生成一个新的反向提交、相当于用一次新提交抵消旧改动。git reset有三个常用级别。--soft只移动 HEAD 回到目标提交改动全部留在暂存区--mixed默认把改动退回工作区--hard直接丢弃所有改动工作区、暂存区、分支指针全部回到目标提交状态。--hard是条单行道执行前必须确认最好git log记下当前提交哈希万一后悔还能用git reset --hard 原哈希找回。git revert不修改已有提交历史更适合已经推送到远程的分支。比如你发布了 v1.2 之后发现某个功能有 bug用git revert 提交哈希生成一个相反提交把该功能去掉历史里会清楚记录这次撤销。多提交连撤可以用git revert 旧提交..新提交。在多人协作分支上我几乎只用 revert 不用 reset因为它不会给同事造成历史错乱合作起来更文明。5.3 半路想切分支stash 优雅暂存现场开发到一半突然要切分支去改热修复但改动不想丢弃也不想提交。git stash会把你工作区的改动存到一个临时栈中让工作区恢复干净。之后切分支、该干嘛干嘛事后再回到这个分支执行git stash pop改动就会弹回来如同从未离开。git stash list查看暂存列表我可以为你恢复指定一条git stash apply stash{1}。apply不会删除栈中的记录pop会弹出并删除。如果 stash 后你的工作区因为后续改动而冲突pop会报冲突但 stash 记录还在解决冲突后git stash drop手动清理就行。我用 stash 还有一个高级习惯git stash push -m 描述信息给每次暂存写个标签。因为 stash 默认只显示WIP on branch: 哈希值过几天再看根本想不起当时存的是什么加上描述后辨识度立即提升。如果你并不少会感谢这个习惯的。另外现在 Git 2.23 提供了git switch的邻居git restore以及git stash push都是为了把各种多语义命令做拆分让操作更安全清晰。新学 Git 的同学建议直接养成这个新式命令习惯老同学想改也不难。6. 常见问题排查速查表直接翻答案6.1 分离头指针Detached HEAD状态当你git checkout 某个提交哈希而不是分支名时HEAD 不指向任何分支进入 Detached HEAD。这个状态下新提交不会属于任何分支一旦切走很容易丢失。如果确实需要在某个历史提交上做改动先git switch -c 新分支名基于当前状态创建分支再接续开发。如果只是想看看代码什么都不改、直接切走即可。6.2 提交提交错了分支把功能提交到了 main而不是 feature/login。别慌先记下那个提交的哈希执行git switch feature/login然后git cherry-pick 哈希把这个提交复制到当前分支。回到 main 后如果该提交是最近一次且还没推送git reset --hard HEAD~1把它从 main 移除如果已经推送到远程就用git revert生成反向提交。整个过程其实比很多人想象中简单关键是动手前先想清楚分支指针的移动路径。6.3 合并冲突进行到一半想放弃内容冲突甚至文件冲突比如两边都改动了同一个二进制文件名导致合并卡住时可以用git merge --abort回到合并前状态。这个命令在 rebase 场景对应git rebase --abort。切记先保存你手动改过的中间内容否则 abort 之后那些半成品也会一起消失。6.4 持续提示输入用户名密码以前遇到这类问题通常靠 credential helper 配置解决而 2021 年后很多平台不再支持账号密码直接 push推荐使用 SSH key 或 token 方式认证。如果git push反复失败或要求输入口令先用ssh -T git平台域名以实际平台为准诊断 SSH 是否连通再检查本地仓库的 remote 地址用的 HTTPS 还是 SSHgit remote set-url origin可以随时切换地址格式。日常建议用 SSH 认证配置一次长期省心。6.5 误把大文件提交进仓库Git 对仓库大小非常敏感一旦提交了类似编译产物的大型二进制到历史记录中即使之后删掉文件这个膨胀仍会留在 .git 历史里。若提交还未推送用重置或 amend 都行若已推送且历史较深需要工具重写历史这一操作复杂且会改写全部提交哈希。更根本的预防方案是把不需要跟踪的文件放进.gitignore例如node_modules/ dist/ *.log .DS_Store.gitignore是每个仓库第一件应该做好的事。下面我把高频遇到的问题整理成一张对照表方便你直接查阅症状成因推荐命令工作区改乱了想还原未 add 的修改git restore 文件名add 多了想退出来暂存区内容不需要git restore --staged 文件名提交信息打错了提交未推送或仅本地git commit --amend最近一次提交想撤销未推送提交到错误分支git reset --soft HEAD~1已推送的提交想撤销公共历史不能改写git revert 提交哈希切换分支但想保留现场工作区未提交改动git stash push -m 描述合并冲突想放弃中间状态太乱git merge --abort推送到远程被拒绝远程有新提交git pull --rebase后重推查找某行代码是谁改的定位回归来源git blame 文件名每张表其实都浓缩了一个完整场景的前因后果。我把这个表做成了一张实体便签贴在显示器旁边前几周频繁翻之后基本不看了因为反复几次肌肉记忆自动形成。你也可以试试这个土办法。我个人在实际操作中的体会是Git 命令学的不是数量是模型。你不需要背下所有参数只需要清楚地知道工作区、暂存区、版本库、远程这四个层级再想清楚每条命令在这四层之间搬运了什么内容、移动了什么指针就不会在出现冲突或误操作时手忙脚乱。后面我每次换新环境第一件事就是把.gitignore写好把默认提交信息规范用文本存到本地配置文件里避免临时拼凑。建议你也找一个小项目按这篇文章的流程从头到尾练两遍分支和远程操作把害怕冲突变成预判冲突那种感觉会很不一样。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
