前一阵带新同事熟悉项目，他一边翻Git命令手册一边叹气，说命令太多，背了又忘，干脆继续用图形界面。我给的建议是：别背，就把15个命令用熟，足够应付日常开发了。这篇聊聊我筛选出的这15个Git核心命令，从git init到git push，它们刚好串起一条完整的开发链路：本地写代码、提交、切分支、合并、同步远程、审查改动。不管你是刚接触Git的新手，还是在图形工具和命令行之间徘徊的开发者，都能在这篇里找到可以直接照做的用法，以及在真实项目里爬过的坑。
1. 从命令手册到高频实战：我筛选核心命令的标准
先声明一下，Git官方文档里光是最常见的命令就有上百个，你翻完一遍之后根本记不住，也没必要记。日常开发里反复用到的、能让工作流跑通的核心命令，我用几年时间统计下来，其实就15个：init、add、commit、status、log、branch、checkout、merge、stash、clone、remote、fetch、pull、push、diff。
这15个不是拍脑袋挑的，它们覆盖了四条主线。第一条是本地仓库的生命周期，从init创建仓库，到add把改动放进暂存区，再到commit落成一次提交，中间用status随时看状态，用log回看历史。第二条是分支操作，branch管理分支列表，checkout切换分支，merge把分支合回来，碰到临时要保存现场就靠stash。第三条是远程协作，clone把远程仓库搬下来，remote管理远端地址，fetch只下载不合并，pull拉取并合并，push推送本地提交。最后一条是提交前的审查，用diff检查这次到底改了什么。
说实话，这15个命令覆盖了绝大多数常规开发场景。像config、reset、revert、tag这些命令也很重要，但它们的定位是“配置类”或“修复类”工具，属于有了基础操作之后再去补的扩展能力。我见过一些开发者连add和commit都还没练熟，就整天研究reset的回退模式，结果工作区一团糟。正确的路径应该是先把主干跑通，再去补枝叶。
我还有一个很主观的筛选标准：凡是能用图形界面替代且不损失效率的命令，先排除；凡是排除不掉、或者命令行明显更好用的，留下来。比如git add -p这类交互式命令，图形工具体验并不差，不算核心；而git status、git diff这种高频操作，在命令行里比图形工具扫一眼更快的，必须入选。这个思路也建议新手参考。
2. 本地提交闭环：init、add、commit、status、log
2.1 init：初始化仓库时被忽略的几个细节
git init是每个项目的第一脚，命令本身简单到一行，但我在帮同事排查时发现，很多人对“当前目录到底有没有被初始化”这件事并不敏感。最典型的场景是：在项目根目录里操作，明明文件都在，Git却不认识，多半是git init没执行成功，或者在错误的目录层级执行了。
git init这条命令执行后，会在当前目录生成一个隐藏的.git目录，它才是仓库的灵魂。少了这个目录，Git只是一堆命令而已。实操中我习惯在初始化后立刻执行一次git status确认状态输出正常，同时检查一下git config user.name和user.email是否已配置。这两个字段会写进每一次提交里，如果没配置，后面commit时会报错，或者提交人的名字显示成一串奇怪的字符。
有个小习惯值得分享：初始化项目时，提前建好.gitignore文件，把node_modules、target、.env这类编译产物和敏感配置排除掉。这样后面每次git status看到的都是干净的文件列表，不会被几千个第三方依赖刷屏。热词里的“git 的过滤文件没有作用”多半就是这里出了问题——文件没被忽略，常见原因是.gitignore里写的是绝对路径、或者文件已经进了版本库，纯靠.gitignore是管不住已跟踪文件的，需要用git rm --cached把它从索引里移出去。
2.2 add与暂存区：为什么Git不让你直接commit
很多刚从SVN转过来的同事问我：既然最终都要提交，为什么非要先git add再git commit，多此一举。这个设计恰恰是Git最聪明的地方，它把提交拆成了两个步骤，中间隔着一个暂存区（index）。
git add file.txt git add . git add src/ # 按目录添加暂存区可以理解成一个“购物车”。你在超市里不是拿到一件商品就去结账，而是先放进购物车，等所有想买的东西都挑好了，统一去收银台。git add就是把改动一件件放进购物车，git commit才是结账，生成一个不可变的快照。这个中间层的价值在于，你可以在一次提交里精心挑选要包含的文件，而不是把工作区里乱七八糟的所有改动一顿打包。
实际工作中，我几乎每天都会用s git add -p来分块暂存（这个问题在前面我提过，命令行体验比图形工具可控得多）。比如一个文件里改了功能代码，又临时加了一行调试日志，用git add -p可以把这两部分拆开，只暂存功能代码。缺点是它对新手不太友好，但一旦掌握，提交历史的整洁度会立刻提升一个档次。
2.3 status：区分三种状态，别被红色吓到
git status是我在终端里敲得最频繁的命令，没有之一。它的价值是告诉你“现在仓库处于什么状态”，并且把不同状态的改动用颜色区分：红色表示未暂存的改动，绿色表示已暂存，还有一类文件既不红也不绿，说明它从没被跟踪过。
git status新手最常见的困惑是：满屏红色，以为自己把仓库搞坏了。其实红色只是“调色板”，它反而说明Git看到了你的改动，等着你决定怎么办。我看到很多老手在工作前也会先敲一遍git status，确认自己“现在在哪个分支、工作区是否干净”，这个动作像开车前看仪表盘一样，能避免后面一系列误操作。
我还有一个个人习惯：每次在提交之前，先跑git status，再跑git diff，最后才是git add和git commit。status告诉你改了哪些文件，diff告诉你每处改动到底是什么，这两步走完，提交的内容心里有底，不会出现“这个文件我怎么没发现也被提交了”的后悔。
2.4 commit：提交信息规范与--amend修改
git commit是生成提交快照的命令，最常见的写法是把暂存区里的内容全部提交：
git commit -m "fix: 修复登录接口超时问题"提交信息是写给未来读代码的人看的，包括未来的自己。我一般遵循type: 描述的约定，type用feat表示新功能、fix表示修复、refactor表示重构、docs表示文档变更。别小看这个习惯，当你三个月后回头翻历史时，一眼就能看出某次提交的目的，比那些“update”“fix bug”的模糊信息好用太多。
热词里专门有人问git commit --amend怎么使用，这个命令的全貌是：修改最近一次提交。用法分两种，一种是想修改提交信息，另一种是想补提交漏掉的文件。
git commit --amend -m "feat: 新增用户注册接口" git add forgotten-file.txt git commit --amend --no-edit # 补文件，但保留原来的说明--amend的原理不是真的“修改”历史提交，而是把当前提交覆盖成一条新提交，旧提交会被替换掉。所以这里有两条铁律：第一，如果上一次提交已经推送到远程，并且别人可能已经拉取了，就不要再用--amend，不然会制造历史分叉；第二，--amend是修改历史，使用前再确认一遍暂存区，别把不相干的改动卷进来。
2.5 log：读提交历史的正确姿势
git log把人从“我不知道项目改了什么”的焦虑里解救出来。它的输出默认是一个接一个的提交记录，每个记录带哈希值、作者、日期和提交信息。
git log git log --oneline --graph --all # 我最常用的简写形式 git log -5 # 只看最近5条--oneline让每条提交压缩成一行，--graph画出分支拓扑，--all把其他分支的提交也包含进来。我强烈建议把它设置成一个别名，因为每次敲这么长一串实在太累：
git config --global alias.tree "log --oneline --graph --all --decorate"以后一条git tree就能看到整个仓库的分支走势，谁跟谁合过、怎么回事，一目了然。如果想知道某次提交具体改了什么，用git show <hash>，它相当于diff和log的结合体。
3. 分支的创建、切换与合并：branch、checkout、merge
3.1 branch：认识分支的本质——指针
很多刚接触Git的人以为分支是文件夹的完整副本，切过去就相当于复制一份代码。实际上，Git分支只是一个指向某个提交对象的指针，它轻量到可以瞬间创建和删除。所以Git对分支的态度极其随意，鼓励你频繁开分支、频繁合并，不用担心成本。
git branch feature/login git branch # 列出本地分支，当前分支前面有个 * 号 git branch -d feature/login # 删除已合并的分支 git branch -D feature/login # 强制删除，即使未合并我在团队里一直推行的分支策略是：主干分支永远保持可发布状态，新功能在独立分支上开发，完成后合并回主干。-d和-D的区别值得一提，-d会检查分支是否已合并，如果没合并会阻止你删除，这是Git的保护机制；-D是顶级人字拖，直接脱了删，如果你的改动还没合并，用-D之前先想清楚。
3.2 checkout与switch：切换分支前先看工作区
git checkout是Git里功能最杂的命令之一，既能切分支，又能恢复文件，还能创建新分支。它的核心切换分支能力，在老版本里是唯一正解：
git checkout feature/login git checkout -b feature/new-feature # 创建并切换Git 2.23之后官方推荐了更语义化的git switch，专门负责切换分支：
git switch feature/login git switch -c feature/new-feature # 创建并切换之所以后来拆出switch，就是因为checkout负载太重，同一个命令干了好几类事，新人容易搞混。我个人从2.x版本之后，新习惯都是用switich切分支，用checkout恢复文件。这里提醒一个高频报错：当你本地有未提交的改动，而目标分支和当前分支在这些文件上有冲突时，切换会被拒绝。不要慌，先把改动stash起来，或者确认改动完好后再切。
3.3 merge：快进与非快进合并
git merge负责把另一个分支的提交合并到当前分支，它是“分支没有白开”的临门一脚。
git switch main git merge feature/login合并有两种形态。第一种叫快进（fast-forward），发生在当前分支没有新提交时，Git直接把main的指针移到feature/login的位置，看起来像一条直线。第二种叫三方合并，发生在两条分支各自有提交时，Git会找出两个分支的共同祖先，再把两个分支各自的改动合成一个新提交。热词里的“git分支合并”问得最多的就是：为什么合并之后多了一个Merge branch ...的提交？原因就是你做的是三方合并，多出来的那个提交就是合并提交，它把两条分叉的道路重新拧在一起。
我建议在合并主干之前，先跑一遍测试、看一遍diff，不要在状态不明的情况下盲目标签合。合并完成后，如果发现问题要回退，可以用git merge --abort取消合并，条件是冲突正在进行中。
3.4 合并冲突的解决：先读标记，再动手
最让新人胆战心惊的就是冲突（conflict）。其实冲突不是Merge错了，而是Git在告诉我们：它自己实在搞不定，需要人类做决定。冲突发生时会生成一批包含特殊标记的文件：
<<<<<<< HEAD 这是当前分支的版本 ======= 这是被合并分支的版本 >>>>>>> feature/login中间的=======是分界线。做法就是打开文件，把不需要的一边删掉，保留正确的代码，然后处理所有标记，保存文件，最后：
git add 已解决的文件 git commit记住一个原则：冲突是一场人工三目运算，Git只是老实人如实报告了对齐偏差。不要重复造轮子，遇到重大冲突，可以开个工具来对比。对了，解决完冲突之后的提交不要加-m让它自动填一份合并信息，否则后续排查时背景信息就丢了，我一般会在提交信息里写明“合并feature/login解决#12接口冲突”。
3.5 stash：临时保存未提交改动
git stash本来不在我最初的核心清单里，但用久了发现，它在分支切换场景里几乎是个必选项。想象一下：你在feature/login上改到一半，组里说线上有个bug要立刻去main分支修，你又不想把半成品提交上去。这时候直接切分支会被Git拒绝，而临时提交又污染历史，正确解法是：
git stash # 把当前改动暂时收起来，工作区变得干净 git switch main # 修完bug回来 git switch feature/login git stash pop # 恢复之前暂存的改动stash把暂存区里保存成一个栈结构，所以git stash list能看到历史，git stash pop弹回最新一条。偶尔遇到弹回时代码冲突，这是我的处理链路：检视冲突文件，手动解决，然后git stash drop清掉那条，避免重复应用。这个命令还有个高频场景是git pull前工作区不干净，也常靠stash解救，拉完再弹回来。
4. 连接远程：clone、remote、fetch、pull、push
4.1 clone：克隆仓库后的第一件事
git clone是把远程仓库完整复制到本地的命令，相当于“买房直接拎包入住”，历史记录、分支、标签全部一起搬过来。
git clone git@github.com:user/repo.git git clone https://github.com/user/repo.git git clone --depth 1 git@github.com:user/repo.git # 浅克隆，只要最新快照热词里有个“SSH认证失败 git”，就是这个环节最痛的坑。我用SSH协议用的最多，但前提是本地要先生成密钥并添加到平台：
ssh-keygen -t ed25519 -C "you@example.com" cat ~/.ssh/id_ed25519.pub # 把公钥复制到 GitHub/GitLab 的SSH Key设置里如果克隆时提示权限被拒绝（Permission denied），九成是公钥没装上去，或者装了之后用户名不对，可以先跑ssh -T git@github.com验证连通性。关于“git免密”，远程地址用SSH格式后，密码换了都不影响push，这是最持久的免密方案；如果用的是HTTPS地址，可以用凭据管理器或者配置credential.helper，但这些方案在面对多账号时都比较麻烦，我自己是SSH流派。
4.2 remote：管理多个远程地址
一个本地仓库可以关联多个远程地址，origin只是第一个远程仓库的默认名字。git remote就是管理这些地址的入口：
git remote -v # 查看所有远程地址 git remote add upstream https://github.com/upstream/repo.git git remote remove old-origin我参与开源项目维护时，通常会有两个远程：一个origin指向自己fork的仓库，一个upstream指向官方仓库。提PR之前先git fetch upstream，再把自己的主张合并进来，这个流程没有remote命令根本没法优雅完成。每次改动远程地址后，及时用remote -v确认，别让URL悄悄指向了一个消失的地址。
4.3 fetch与pull的区别：安全下载与主动合并
很多人刚接触时根本分不清fetch和pull，因为敲pull的效果看起来一次就完成了。这两者的区别，一句话就能说清：fetch只把远程提交下载到本地仓库，不动你的工作区；pull等于fetch加merge，一把梭。
git fetch origin git pull origin main我自己的分工是：在干净状态下、想看远程有哪些新东西时，就只fetch，接着手动决定下一步动作。这就像快递员把包裹放到了驿站，你没有被强行拆包。需要把自己的工作区和远程同步时，才交给pull。如果你比较想保持历史的线性，可以加--rebase参数让它用rebase的方式合并，但条件是确保自己对rebase的概念有把握，不然容易出现“我怎么多了好几个重复提交”的困惑。
4.4 push：推送失败、上游分支和免密登录
git push把本地提交送到远程仓库，是整个流程的终点。新建立的分支第一次推送时有个经典写法：
git push -u origin feature/login参数-u是--set-upstream的简写，意思是把本地分支和远程分支的跟踪关系固定下来。设置过之后，以后在这个分支上直接git push、git pull都不用再写远程和分支名。如果不加这个参数，第二次push时Git会提示你指定远程参数，一点都不舒服，建议养成“新分支第一次推送就用-u”的习惯。
push被拒绝是家常便饭，最常见的原因是远程有别人提交的改动，而你的本地基于旧版本。此时不要盲目git push --force，这是最危险的核弹操作，会覆盖远程历史。我的常规链路是：git pull --rebase先拉取远程改动，把自己的提交重放到最新提交之后，再重新push。偶尔用push --force-with-lease修正自己刚推出去又后悔的内容，这个参数比--force安全，它带了校验，不会冲掉别人在远程的新提交。
4.5 理解跟踪关系：分支不迷路的底层原理
前面提了好几次“跟踪关系”，这个概念值得多说一点。本地分支与远程分支的映射关系，是Git协作的大脑。用git remote里的origin，加上分支名字，组成了origin/feature/login这种远程跟踪分支。它们不是真实存在的分支，而是记录“我上次跟远程同步时，那个分支指向哪儿”的快照。
git branch -vv # 查看跟踪关系如果你发现某个本地分支后面没有显示“追踪 origin/xxx”，说明它还没设置上游关系，一般在第一次push时加-u就能解决。排查“为什么我push不上去”的时候，先用git branch -vv看跟踪关系，再用git fetch看远程位置，这两步能解决八成同步类问题。
5. 提交前的最后一道审查：diff与log的组合用法
5.1 diff的三种对比范围
git diff是审查改动的核心工具，它能回答“我到底改了哪一行”。三种用法对应三种对比范围：
git diff # 工作区 vs 暂存区（还没add的改动） git diff --staged # 暂存区 vs 最近一次提交（已经add的改动） git diff HEAD # 工作区+暂存区 vs 最近一次提交我习惯在写了很多改动后，先git diff看一遍未暂存部分，确认每一处改动都是预期的；接着git add，再git diff --staged浏览一遍即将提交的内容；确认无误后git commit。这个过程能有效防止“把调试用的console.log或者本地配置提交进仓库”的惨剧。
diff默认看全部文件，文件多时会看不过来，我常用两个参数：git diff --stat先看文件级别的增删行数统计，git diff 文件名单独看某个文件。对代码量大的改动，还可以配合git log -p查看历史提交的改动细节，这个组合在Code Review前做快速预审很实用。
5.2 那些和diff/status有关的高频坑
热词里有“git 的过滤文件没有作用”，这个是status和diff环节最常见的坑。排查链路我给你理一遍：首先确认.gitignore文件本身没有被提交、且忽略规则写的是相对仓库根目录的路径；然后确认目标文件是否已经被Git跟踪，如果文件早就在版本库里了，改.gitignore是没用的，必须执行一次git rm --cached 文件路径将其移出版本控制，同时保留本地文件；最后跑git status验证是不是不再出现在改动列表里。
另一个高频坑是“git疑难杂症”类问题里的分支漂移，表现为git status提示你的分支和远程分支差了几个提交，自己又没印象。这种时候别乱动，按这个思路查：git fetch先同步远程快照，git log --oneline HEAD..origin/main看本地缺哪些提交，git log --oneline origin/main..HEAD看本地独有的提交，然后再决定是rebase还是merge。
5.3 用log加diff回溯问题：一条完整的排查链路
遇到“之前还好好的，现在不行了”的问题，我用得最多的排查组合是git log加git diff。某次线上发布后接口超时，同事一个个文件翻代码找原因，浪费了半小时。我的做法是两步走：先git log --oneline -10列出近10次提交，马上锁定发布前最后一次确定的正常版本；再git diff <正常版本hash> <发布版本hash>对比中间所有改动，问题点通常就在增删行最多的文件里。
这种排查思路的基础是提交足够细、信息足够清楚。所以说到底，前面花的那些“写清楚提交信息”的功夫，不是形式主义，都是在给自己未来的排查铺路。Git的提交历史本身就是一个时间机器，你越擅长用log和diff，定位问题的速度越快。
还有一个小技巧，是我用Git这几年最大的体会：不要怕敲错命令。Git有很强的安全保障机制，stash可以临时保存，reflog能找回“丢”掉的提交，branch -d会阻止删掉未合并分支。真正需要害怕的只有三种场景：对已推送的公共历史用push --force、在未确认状态时用reset --hard、以及完全不知道自己在checkout --恢复了什么文件。把这15个命令练熟，遇到问题时多跑一遍status和log，你已经能对付绝大多数日常开发场景了。剩下的命令，等你真的需要时再去查，到那时候你也会知道该查什么。
