机智的娜娜搞技术这么多年，我发现一个怪现象：网上随便一搜“Git常用命令”，出来的文章都是几十上百条命令的罗列，看起来特别全，但真正上手干活的兄弟还是不停百度。原因很简单——命令是死的，场景是活的。你背下来git reset --hard，但没人告诉你什么时候该用--soft；你知道git pull，但遇到冲突还是两眼一抹黑。
我最早接触Git也是一样，照着教程敲了半天，感觉会了，一上项目就露馅。后来把Git的对象模型、三个区（工作区、暂存区、版本库）彻底搞明白之后，那些命令再看一遍就全记住了，因为每一类命令都有它对应要解决的问题。这篇东西我不打算写成命令大全，而是从实际开发流的角度，把我这些年用得最频繁、踩坑最多的Git操作梳理一遍，环境怎么配、提交怎么弄、分支怎么玩、出错怎么救，一条条讲清楚背后的逻辑。哪怕你只看得懂代码不会配环境，或者连Git还没装，照着做也能顺利跑起来。
1. 安装与初始化配置：环境没搭好，后面全是坑
很多教程默认你已经装好了Git，上来就直接将命令，结果Windows用户右键菜单里找不到Git Bash Here，Mac用户发现git命令压根不存在，第一关就卡住了。安装这件事本身不复杂，但有几个细节会影响你后续几个月的使用体验，值得一次性弄对。
1.1 三平台安装，以及Windows下必须勾选的PATH选项
先说Windows。Git官方提供了Windows安装包，下载下来一路Next基本能装完，但有一个关键步骤很多人忽视了：安装到“Adjusting your PATH environment”这一步时，务必选择**“Git from the command line and also from 3rd-party software”**，而不是默认的“Use Git Bash only”。
提示：如果选错了，你后面在PowerShell或者CMD里敲
git --version会直接报“无法将git识别为cmdlet”，还得手动去改环境变量，纯属给自己找事。
装完以后，右键菜单里应该出现“Git Bash Here”。如果没有，去开始菜单搜Git Bash手动打开也行。Git Bash这个东西本质是在Windows上模拟了一套类Unix环境，里面除了git之外还有其他常用命令行工具，比如grep、find、awk。我日常在Windows上做Git操作基本都在Git Bash里进行，它的命令风格和Linux下完全一致，省得在两个终端之间来回适应。
macOS就简单了，装了Homebrew直接一行：
bash复制brew install git
Linux发行版则看包管理器，Ubuntu/Debian系列用apt install git，CentOS/RHEL系列用yum install git，Fedora用dnf install git。装完统一用下面这条命令验证版本：
bash复制git --version
1.2 安装后必做的三个配置：身份信息、换行符、默认分支名
Git装好之后第一件事不是建仓库，而是配置身份信息。你每次提交代码时，Git会把提交者的名字和邮箱记录在提交历史里。如果不设置，第一次commit时Git会直接拒绝，提示：
code复制Please tell me who you are.
这时候需要设置全局用户名和邮箱：
bash复制git config --global user.name "Your Name"
git config --global user.email "you@example.com"
注意这里的邮箱最好和你用的Git托管平台（GitHub、GitLab、Gitee等）注册邮箱保持一致，不然推送上去的提交头像都对应不上。
接下来是换行符问题。Windows系统默认换行符是CRLF（回车+换行），而Linux/macOS用LF（只有换行）。如果大家的Git配置不一致，就会出现一种很头疼的情况：你什么都没改，但git diff显示整个文件全被标记为修改了，因为Git认为换行符变了。
标准做法是Windows用户执行：
bash复制git config --global core.autocrlf true
这样提交时Git会把CRLF自动转成LF存进仓库，检出时再转回CRLF。macOS/Linux用户则执行：
bash复制git config --global core.autocrlf input
只做转换，检出时不转回LF。团队协作时，这个配置的统一比想象中更重要，很多莫名其妙的冲突根源都在这里。
再推荐一个习惯——把默认分支名设置为main：
bash复制git config --global init.defaultBranch main
新版本的Git已经默认这么做了，但如果你的Git版本比较老，git init来创建的默认分支可能是master。统一分支名没什么高深理由，纯粹是为了团队沟通时少一点无谓的认知负担。
1.3 SSH免密配置：推送前最后一道坎
配置好身份和换行符之后，还有一个早晚要面对的问题：推送代码到GitHub/GitLab时，每次都要输账号密码，非常烦人。所以强烈建议一上来就配好SSH密钥，一劳永逸。
生成密钥很简单：
bash复制ssh-keygen -t ed25519 -C "you@example.com"
如果系统不支持ed25519算法（通常是老旧的Linux环境），改用：
bash复制ssh-keygen -t rsa -b 4096 -C "you@example.com"
一路回车即可，默认会生成在~/.ssh/目录下。然后把公钥内容复制出来：
bash复制cat ~/.ssh/id_ed25519.pub
复制完整输出，到GitHub的Settings -> SSH and GPG keys -> New SSH key，或者GitLab的Preferences -> SSH Keys，粘贴保存。保存之后验证连接：
bash复制ssh -T git@github.com
如果看到类似Hi xxx! You've successfully authenticated的提示，就说明SSH链路已经通了。之后clone仓库记得用SSH地址（git@github.com:user/repo.git），而不是HTTPS地址，就能实现免密推送。
有个细节需要注意：如果家里和公司的网络环境切换频繁，偶尔会出现Permission denied (publickey)。这时候先不要着急重生成密钥，用下面的命令确认ssh-agent是否在运行、密钥是否已加载：
bash复制eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
再执行ssh -T git@github.com验证一次，大部分情况都能解决。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 本地提交的三步循环：工作区、暂存区、版本库到底怎么回事
好多人的Git操作卡在“记不住命令”这一层，本质原因是没搞懂Git的三个区域。简单用一个类比：工作区是你正在写的草稿纸，暂存区是收件箱（你决定放进去的文件），版本库是档案室（放进来的东西永久留档）。所有常用的本地提交操作，都是在这三个区域之间搬运内容。
2.1 提交前先看状态：git status和git diff
我见过很多同事上来就是一顿git add .然后git commit，结果经常把不想提交的文件也带进去了。正确习惯是：提交前先看清楚自己改了什么。
git status是最常用的检查命令，我通常加参数简化输出：
bash复制git status -sb
-s是short模式，-b会顺带显示当前分支名和与远程分支的同步状态。输出结果里M代表已修改、A代表新增、D代表删除、??代表未被Git跟踪的文件。这个命令一敲，仓库当前什么状态一目了然。
光知道哪些文件改了还不够，最好再确认一下改动的内容是否符合预期，用：
bash复制git diff
这条命令对比的是工作区和暂存区之间的差异。如果你的内容已经git add进去过，属于“暂存区 vs 版本库”的改动，则要看：
bash复制git diff --staged
养成这个习惯以后，基本告别“提交了一堆垃圾代码还想revert却发现历史已经乱掉”的尴尬局面。
2.2 add的几种姿势与commit的常见组合
git add是将工作区的改动加入暂存区的动作，但未必每次都要一股脑全加。常用的几种方式：
bash复制git add . # 添加所有改动（包括新增文件）
git add src/main.py # 添加指定文件
git add src/ # 添加某个目录下所有改动
git add -p # 交互式按hunk添加，只加部分改动
git add -p是个被很多人低估的功能。比如你一个文件里改了三个功能点，但只想把其中一个提交上去，就可以用-p进入交互模式，Git会把文件拆成若干小块（hunk），问你这个hunk要不要暂存。这在团队协作中非常实用，能保证一次提交只干一件事。
提交本身有几种常用姿势：
bash复制git commit -m "feat: 登录模块增加验证码功能"
git commit -am "fix: 修复并发下的数据错乱问题"
-a参数会自动把已跟踪文件的修改加入暂存区再提交，但注意它不会包含尚未跟踪的新文件，所以新增文件还是得先add。如果提交完发现消息打错了字，或者漏了个文件，别急着重来一次提交，用：
bash复制git commit --amend
这个命令会把上一次提交和当前暂存区的内容合并成一个新提交，同时允许你重新编辑提交信息。它在本地很有用，但如果你已经push到远程了，就不要用--amend去改历史了，否则会和同事的本地记录产生分叉，非常麻烦。
2.3 提交信息怎么写：给未来的自己和队友留一条活路
这一节不是讲命令，但比命令更重要。提交信息写得好不好，直接决定你三个月后翻日志时能不能两分钟定位问题。
业内比较流行的规范是约定式提交（Conventional Commits），格式大致是：
code复制<type>(<scope>): <subject>
其中type常用的有feat（新功能）、fix（修bug）、docs（文档）、style（格式调整）、refactor（重构）、test（测试）。举两个例子：
code复制feat(user): 增加用户注册手机号校验
fix(order): 修复订单超时未取消的问题
这种规范的好处是git log --oneline输出列表时扫一眼就能看懂每次提交在做什么，甚至可以直接拿这个格式去生成CHANGELOG。我看过太多提交信息只写“update”或者“111”的仓库，这种历史除了给自己添堵没有任何价值。
3. 远程协作：clone、fetch、pull、push的真实联动关系
本地提交只是第零步，Git真正的高频场景是多人协作：把代码拉到本地、改动后推回远程、同步别人提交的新内容。这一块命令不多，但理解联动关系比记住命令本身更重要。
3.1 clone与远程分支的关联
把远程仓库整个复制到本地，用：
bash复制git clone git@github.com:user/repo.git
clone下来之后，Git会自动把远程仓库命名为origin，你可以用git remote -v查看远程地址。注意一个细节：clone默认只拉取远程的默认分支（通常是main或master）然后建立本地跟踪关系。其他远程分支虽然在远程存在，但本地并不会自动创建对应的分支。想拉取某个远程分支到本地开发，需要：
bash复制git switch -c feature/login origin/feature/login
-c表示新建并切换分支，这条命令会基于远程的feature/login创建一个同名的本地分支，并自动建立跟踪关系。
3.2 fetch和pull的区别：什么时候该拆开来用
git pull很多教程直接讲“拉取远程代码”，但这句话掩盖了一个重要的中间步骤。实际上git pull = git fetch + git merge。
git fetch只做一件事：把远程的最新提交下载到本地，但不合并到你当前的工作分支。这是它和pull的本质区别。
那什么时候该只用fetch？典型场景是你正在开发某个功能，想看看同事今天提交了什么，又担心直接合并会影响当前正在进行的工作区。这时候先git fetch，然后手动查看：
bash复制git fetch
git log --oneline origin/main..main
后面的命令可以列出本地main有而远程origin/main没有的提交。看完之后心里有数了，再决定什么时候merge。
如果你确定远程没有人和你的改动冲突，直接git pull就够。但有一种情况值得用pull --rebase：
bash复制git pull --rebase
上面这句等于先fetch，再把你本地的提交“叠”到远程最新提交的后面，历史是一条直线。而默认的pull会生成一个merge提交，历史像毛线团一样，虽然信息完整，但读起来费劲。至于merge和rebase选择的问题，下面章节详细展开。
3.3 push的关联参数、常见失败与远程分支清理
推送本地提交到远程，命令本身很简单：
bash复制git push
但这里有个隐含概念——本地分支需要和远程分支建立“跟踪关系”。第一次推送一个新分支时，Git会要求你显式指定远程分支并建立跟踪：
bash复制git push -u origin feature/login
-u是--set-upstream的简写，意思是为当前本地分支设置上游分支，之后再用git push或者git pull就不用再带参数了。
推送失败最常见的报错是：
code复制! [rejected] main -> main (non-fast-forward)
hint: Updates were rejected because the tip of your current branch is behind
这个报错的意思是：远程分支上有你本地没有的新提交。原因可能是同事在你上次pull之后又推送了代码，或者你改动了已经被推送过的历史。解决方案也很直接：先git pull --rebase把本地提交叠到远程最新提交之上，处理完冲突后再git push。
远程分支的清理也是一个被忽略的点。功能合并完之后顺手删除远程分支是基本素养：
bash复制git push origin --delete feature/login
同时清理本地已经合并过、留着只会让分支列表越来越长的分支：
bash复制git branch -d feature/login
如果本地分支有未合并的改动，Git会拒绝删除并提示。这时候如果你想强制删除，把-d换成-D，但用之前确认你真的不需要这个分支了。
4. 分支管理与合并：merge、rebase、cherry-pick各管哪一摊
分支是Git最强大的特性，也是新手最容易玩脱的地方。很多人分不清merge和rebase什么时候用，也不知道cherry-pick为什么存在。这一章把三者放在一起讲，顺便讲讲冲突是怎么回事。
4.1 分支创建、切换与删除：checkout的两种用法
创建并切换分支，新版本的推荐写法是：
bash复制git switch -c feature/login
老版本以及大量教程里用的是：
bash复制git checkout -b feature/login
两者效果一样，只是switch的命令语义更纯粹（只负责切换分支）。不过我日常见到的代码里，checkout -b依然很常见，因为大家都习惯了，也没有必要刻意改。
checkout这个词之所以容易让人困惑，是因为它有两种完全不同的含义：
- 切换分支：
git checkout main - 恢复工作区文件：
git checkout -- src/main.py
后面的用法是把指定文件恢复到最近一次提交的状态（相当于丢弃当前未提交的改动）。新版Git为此也提供了更语义化的git restore src/main.py。我个人的建议是恢复文件时多用restore，切换分支时用switch，命令意图一目了然。
删除已经不再需要的本地分支用git branch -d，前面已经提过。分支命名规范值得多说一句，我基本遵循“类型/功能名”的格式，比如：
feature/login：新功能开发分支fix/payment-timeout：bug修复分支chore/dependency-update：杂项（依赖升级、配置修改等）
团队协作里，一个清晰的分支名能让review的人少猜很多。
4.2 merge与rebase的取舍：历史是直线还是分叉
这是Git世界里争论最多的话题之一。先看两个命令做了什么：
git merge会把目标分支的最新提交和你当前分支的提交合并，生成一个新的合并提交。特点是保留每个分支的完整历史，开发记录忠实反映“谁在什么时候从哪里合并过来”。
git rebase则是把当前分支上独有的提交“摘下来”，一个一个重新应用到目标分支的最新提交之上。最终提交历史是线性的，看起来就像你是基于最新代码一路开发的，没有分叉痕迹。
用一句话总结：merge保留历史，rebase美化历史。
实际开发中，我的经验是这样的：本地开发时，还没有推送过分支，随便rebase，把历史整理得干净漂亮；一旦分支推送到远程并且有同事在基于它开发，绝对不要rebase——因为rebase会重写提交hash，同事的本地历史会和你推送的远程历史发生无法自动合并的冲突，这是“rebase黄金法则”：不要rebase已推送的分支。
对齐远程分支时，推荐用git pull --rebase，这样可以让本地commit保持在远程commit之后，整个提交链是线性的。而合并大型feature分支回主干时，用git merge --no-ff生成一个明显的合并点，反而更利于回溯“这个功能是什么时候合进来的”。
4.3 冲突解决：从产生根源到完整处理流程
有合并就有冲突。冲突的本质是：两个分支修改了同一块内容，Git无法自动判断该保留哪个版本。
模拟一个常见场景。分支A和分支B同时修改了config.yml里的第10行，当你在分支A上执行git merge B时，Git会提示：
code复制CONFLICT (content): Merge conflict in config.yml
Automatic merge failed; fix conflicts and then commit the result.
此时打开冲突文件，会看到冲突标记：
code复制<<<<<<< HEAD
port: 8080
=======
port: 9090
>>>>>>> B
<<<<<<< HEAD到=======之间是当前分支的内容，=======到>>>>>>> B之间是合入分支的内容。你需要手动决定保留哪个，或者改成一个新值。编辑完成后：
bash复制git add config.yml
git commit
如果你想放弃这次合并、回到合并之前的状态，用：
bash复制git merge --abort
处理rebase冲突时，同样需要手动编辑冲突文件，然后：
bash复制git add config.yml
git rebase --continue
如果rebase过程中发现越弄越乱，可以：
bash复制git rebase --abort
回到rebase之前的状态。
4.4 cherry-pick：只想移植一个提交时用它
有时候你不需要合并整个分支，只需要把另一个分支上的某个提交挪过来。比如线上出了个bug，修复提交在develop分支上，但你只想把它同步到main分支，不想把整个develop合并过来。这时用：
bash复制git cherry-pick 7f3a9d2
后面的参数是目标提交的hash（可以用git log --oneline查看）。cherry-pick会把这个提交的改动应用到当前分支上，并生成一个新的提交。如果同一批提交需要连续移植，可以用区间：
bash复制git cherry-pick A..B
这个命令会移植从A之后到B之间的所有提交。不过用之前先确认A是B的前祖先提交，否则会报错。简单场景还是一个个挑比较稳妥。
5. 撤销与回滚：这些“后悔药”适用的场景各不相同
Git给你准备了好几层后悔药，但每种药治的病不一样，用错了反而会加重病情。写代码难免手误，关键是选对对应的命令。
5.1 还没提交但改乱了：从工作区恢复
如果你改动了一个文件，但发现改得稀烂，想恢复到最近一次提交时的样子，用：
bash复制git restore src/main.py
或者等价的旧命令：
bash复制git checkout -- src/main.py
注意这种操作是不可逆的，命令执行后未提交的改动直接消失。所以我在执行恢复文件之前都会先看一眼git diff，确认这些改动真的不想要了。如果拿不准，宁可先git stash保存起来（后面会讲），也不要一冲动直接恢复。
如果你执行过git add，文件内容已经到了暂存区，想撤销“暂存”这个动作本身，把状态改回未暂存：
bash复制git restore --staged src/main.py
这只是把文件从暂存区“拿出来”，文件内容不受影响。
5.2 提交后发现错了：reset的三种模式
如果你已经提交了，但发现提交内容有问题，想回退到之前的某个提交，用git reset。三种模式对应三种回退程度：
bash复制git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1
--soft：只移动HEAD指针，工作区和暂存区都不动。相当于“撤销了一次commit操作，但保留改动和暂存状态”，改完代码可以重新commit。--mixed（默认）：移动HEAD，重置暂存区，但保留工作区改动。相当于“撤销commit和add，但保留你的修改内容”。--hard：移动HEAD，重置暂存区，并且丢弃工作区所有改动。这是最狠的药，执行完什么都没了。
HEAD~1表示当前提交的上一个提交，HEAD~2表示上上个，以此类推。也可以用具体的提交hash替代。
关于reset有一条铁律：不要用它回退已经推送到远程的提交。原因还是历史重写。如果你回退了本地，强推远程（git push --force），会导致同事的本地历史混乱，等着你的就是一场灾难。
5.3 已经推送到远程：用revert生成一个反向提交
如果错误提交已经推送到了远程，正确做法是git revert：
bash复制git revert 7f3a9d2
这条命令会生成一个新的提交，把目标提交的改动反向覆盖回去。好处显而易见：它不重写历史，只是追加了一个“撤销”提交。这样所有人的本地历史都是兼容的，push时也不会报冲突。
如果你需要对merge提交执行revert，直接执行会报错，需要指定主分支：
bash复制git revert -m 1 7f3a9d2
-m 1表示保留merge提交的第一父分支（通常是你当前所在的主干分支）上的内容。
5.4 git stash：把没干完的活先放一边
场景描述：你正在功能分支上改代码，改了一半，突然线上出了紧急bug，需要立刻切回主分支修东西。这时候工作区的半成品不想提交，直接切换分支还会报错（因为有未提交的改动），怎么办？
git stash就是为此设计的。它可以把工作区和暂存区的改动“压成一坨”暂时存放起来，让工作区恢复干净：
bash复制git stash push -m "登录验证码功能开发中"
切回主分支修完bug之后，再切回来，恢复刚才的改动：
bash复制git stash pop
如果想查看当前保存了哪些stash：
bash复制git stash list
某个stash不想用了，就删除：
bash复制git stash drop
细节提醒：如果开发中新增了文件但还没有git add，git stash默认不会收藏这些未被跟踪的文件。需要加-u参数：
bash复制git stash push -u
再加上前面的-m就是：
bash复制git stash push -u -m "新增了工具类还没提交"
6. 高频报错排查：从报错信息反推根因的完整链路
Git报错信息看起来吓人，实际上大部分高频错误就那几种。排查报错时最忌讳“盲试”，正确做法是先看报错信息里说了什么，再反推根因。
6.1 fatal: not a git repository (or any of the parent directories): .git
这个报错的大白话翻译是：当前目录不是Git仓库，且上级目录里也没有Git仓库。
排查链路很简单，按顺序执行以下几步：
- 用
pwd确认当前目录是不是你以为的那个目录 - 用
ls -a看看目录下有没有.git这个隐藏文件夹（.git文件夹存在，说明这是个Git仓库） - 如果确实没有，说明这个目录还没执行过
git init；如果项目是从远程clone下来的，别急，先看看是否误进了子目录
还有一种容易误导的情况：你在/project下能正常运行Git，但cd到了/project/src后执行git log却报同样错误。这通常是.git文件夹本身出了问题，或者git rev-parse --show-toplevel找不到仓库根目录。可以用：
bash复制git rev-parse --show-toplevel
这条命令会输出仓库根目录绝对路径，对排查一些.worktree或者子模块的诡异情况很有帮助。
6.2 无法将“git”项识别为cmdlet、函数、脚本文件或可运行程序的名称
这个报错Windows用户基本都见过，说明系统在环境变量PATH里找不到git可执行文件。Root cause就两个方向：
第一，安装时PATH选项选错了，Git没有加入系统环境变量。解决办法有两个：回到Git官网下载安装包重新跑一遍安装流程，到PATH那一步选择“Git from the command line and also from 3rd-party software”；或者手动把Git的cmd目录加到系统环境变量里，典型路径是C:\Program Files\Git\cmd。
第二，是安装确实成功，但你在CMD/PowerShell里打开的窗口是早于安装时间启动的。Windows终端的环境变量是在窗口启动时读取的，装完Git后再开的终端才能识别到新PATH。这时候把终端全部关掉重新打开即可，不用瞎折腾。
验证是否恢复正常的标准命令：
bash复制git --version
如果能看到版本号，说明PATH已生效。
6.3 Login failed / Permission denied：认证链路的排查顺序
这类报错包含几种常见形态：
- GitLab客户端报
Login failed. Check API token or GitLab version - SSH方式推送时报
Permission denied (publickey) - HTTPS方式推送时反复要求输密码但认证失败
排查顺序我建议固定为：远程地址 -> 凭据/密钥 -> 网络链路。
第一步，先确认远程仓库地址用的是哪种协议：
bash复制git remote -v
如果是https://开头的地址，但你的账户其实配置过SSH key，那HTTPS推送免不了要输入用户名密码或访问令牌（Personal Access Token）。解决办法要么改用SSH地址，要么在HTTPS推送时输入token而非登录密码。
如果是git@开头的SSH地址，则按以下顺序排查：
bash复制ssh -T git@github.com
看到“Permission denied (publickey)”说明SSH认证没通过。这时候检查：
- 密钥是否生成过：
ls ~/.ssh/，没有则按前面第1章的流程生成 - ssh-agent是否在运行、密钥是否已加载：
ssh-add -l，为空则执行ssh-add ~/.ssh/id_ed25519 - 公钥是否添加到了托管平台账户上：
cat ~/.ssh/id_ed25519.pub，把内容复制过去确认 - 服务器时间是否和本机偏差过大，SSH要求时间同步是硬性的，时区差别小问题不大，时间差几分钟以上就会出问题
6.4 误删分支后的后悔药：git reflog
这一节算是压箱底的内容。如果你执行了git branch -D误删了一个分支，或者git reset --hard把提交搞丢了，先别慌，Git在本地有一个“操作日志”记录着你所有的HEAD移动轨迹，它就是git reflog。
bash复制git reflog
输出类似这样：
code复制8f82a3e HEAD@{0}: reset: moving to HEAD~2
3bc1a9f HEAD@{1}: commit: feat: 增加订单导出功能
每一行的HEAD@{数字}代表“第几步”前的HEAD位置，哈希值则是当时的提交。找到误删分支或误reset之前的那个哈希，然后恢复：
bash复制git checkout -b feature/recover 3bc1a9f
这个命令会在那个提交位置创建一个新分支，相当于把误删的分支“捞”了回来。只要这个提交在reflog里存在，理论上任何误操作都能找回。
注意：reflog记录的是本地操作历史，有效期默认90天。如果时间太久，记录被清理了就真没了。所以误操作之后的第一反应应该是关掉终端，冷静想一想，然后打开reflog，而不是继续敲命令碰运气。
最后再分享一个提升日常效率的小技巧：给高频命令配置别名。把git log --oneline --graph --decorate这种长命令缩成git lg，把git checkout -b缩成git cb，配置也很简单：
bash复制git config --global alias.lg "log --oneline --graph --decorate"
git config --global alias.cb "checkout -b"
这个看个人习惯，但对高频场景确实能省不少时间。Git这个东西，真正用得溜的人不是记住了一堆命令，而是脑子里有一张“场景->解决路径”的图。这篇写的都是我在真实项目中踩过坑、脱过敏之后沉淀下来的高频操作，你在复现的时候如果遇到什么和我的描述对不上的地方，欢迎留言讨论，我再帮你拆解。