刚接手一个项目，第一件事就是git clone把代码拉下来；改完代码要提交，git add、git commit、git push三连；分支乱了要合并，改错了要回滚，远程仓库连不上要排查。这套流程，只要是写代码的人，几乎每天都离不开。但说实话，很多人在Git上栽跟头，不是栽在功能复杂的操作上，而是栽在最基础的常用命令没吃透——要么是不理解每个命令背后的机制，要么是遇到报错不知道怎么排查。
这篇文章我想从一个多年实际使用的角度，把Git最常用的一批命令重新梳理一遍。不会止步于“这条命令是干什么的”，而是会讲清楚它为什么这么设计、在什么场景下用、有哪些容易踩的坑。不管你是刚接触Git的新人，还是用了很久但总是靠复制粘贴救火的开发者，这篇文章都值得花二十分钟读一遍。
1. 从零开始：一次完整的Git安装与全局配置
1.1 安装Git：Windows、Linux和macOS各有各的坑
先解决“有没有”的问题。很多新手遇到的第一道坎，就是在终端里敲git却提示“无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”或类似的“command not found”。这个提示的意思是：你的系统里压根没装Git，或者装了但没把可执行文件所在目录加进环境变量。
Windows上安装Git，最主流的方案是去Git官网下载安装包，一路下一步。但有几个选项需要留意：
- 安装路径：尽量避免带空格的路径，虽然Git官方安装包能处理空格，但后续某些脚本工具可能因为路径空格出问题。
- 默认编辑器：安装过程中会让你选Git使用的默认编辑器，建议选Vim以外的简单编辑器，或者干脆选Notepad++，避免新手误入Vim不知道怎么退出。
- PATH环境变量：建议选“Git from the command line and also from 3rd-party software”，这样Git会注册到系统PATH里，你在任何终端都能直接用
git命令，而不用每次都打开Git Bash。
Linux上就简单多了，不同发行版用对应的包管理器：
# Debian / Ubuntu sudo apt update && sudo apt install git -y # CentOS / RHEL / Fedora sudo yum install git -y装完以后验证一下版本，确认安装成功：
git --version这里补充一个被问得很多的细节：Git for Windows 自带的 Git Bash 是什么？它本质上是在Windows上模拟了一套类Unix终端环境，让你能使用Linux风格命令（如ls、pwd、grep）来操作文件，同时直接调用Windows里安装的Git。所以不少Linux常用命令迁移到Windows后，第一反应就是打开Git Bash，这也是“linux常用命令”和“git bash”这两个热词经常一起出现的真实原因。但注意，Git Bash并不是完整的Linux虚拟机，它不包含apt这类包管理器，也不能直接运行所有Linux软件，只能在它提供的工具集范围内使用。
1.2 安装后的全局配置：身份、编辑器、换行符都要设好
Git装好以后，第一件事不是急着clone代码，而是先配置你的身份。Git每次提交都会记录“作者”和“提交者”，这个信息来自全局配置，如果没配，提交时会报错或者使用一个默认的占位信息。
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这里有个容易混淆的点：user.email只影响提交记录的展示，并不会真的去验证这个邮箱是否存在。很多人在公司代码库里用私人邮箱提交，导致代码统计漏掉自己的贡献，这类问题就是配置不当引起的。建议公司项目配置公司邮箱，开源项目可以用个人邮箱，如果项目内部要求统一，也可以在具体仓库里覆盖全局配置：
cd 项目目录 git config user.name "项目专用名字" git config user.email "项目专用邮箱"除了身份信息，还有两个值得在全局配置里提前设好的选项。
第一个是提交时使用的默认编辑器，避免某些场景下Git会突然弹出Vim界面让你措手不及：
git config --global core.editor "vim"如果实在不会用Vim，可以换成nano或者VS Code的等待模式。注意，如果你在Windows上配置VS Code作为编辑器，命令要写成code --wait的形式，否则Git无法感知编辑器窗口已关闭。
第二个是换行符处理。Windows和Linux/macOS的换行符不一样，Windows用CRLF，Linux和macOS用LF。如果不做任何配置，跨平台协作时会出现“明明没改代码，git diff却显示整文件都变了”的情况。建议统一配置：
# Windows上，提交时转成LF，检出时转成CRLF git config --global core.autocrlf true # Linux/macOS上，提交时转成LF，检出时保持LF git config --global core.autocrlf input这里面的原理可以简单理解成：Git在存储文件内容时，有自己的内部对象数据库，它会按配置把工作区的换行符转换成仓库里统一的形式。autocrlf true表示在提交时把CRLF转成LF，检出时把LF转成CRLF；input表示只做提交时的转换，检出时不转。另外，仓库根目录下的.gitattributes文件可以更精细化地控制换行符规则，如果团队有统一要求，建议以.gitattributes为准。
1.3 查看和维护配置：git config 的常用组合
配置设完，随时可以用git config --list查看当前生效的所有配置项。这个命令会把系统级、全局级、仓库级的配置全部列出来，后设置的项会覆盖前面同名的项。如果你想只查看某一项配置：
git config user.name git config --global --get core.editor配置文件的存储位置也值得知道：全局配置文件在用户主目录下的.gitconfig文件；仓库级配置文件在项目目录下的.git/config文件；系统级配置文件通常在/etc/gitconfig。有时候删配置比加配置还常用，比如你想去掉全局配置中某个设错了的项：
git config --global --unset user.email很多人的Git行为异常，最终定位原因都是“某个配置项在哪个层级被覆盖了”，所以掌握查看与删除配置的基本方法，排查问题会快很多。
2. 日常高频命令：从git init到git commit的完整闭环
2.1 初始化与克隆：git init和git clone的区别
Git操作有两个起点：要么在本地把一个目录变成Git仓库，要么从远程克隆一个已有仓库。
本地初始化：
mkdir my-project cd my-project git init执行git init后，当前目录下会生成一个隐藏的.git目录，这个目录就是Git的“数据库”，存储了所有提交历史、分支指针、配置信息等。此时你的工作区还是空的，Git还没有开始跟踪任何文件。有一点要注意：很多人以为git init之后马上就可以提交代码，其实还要先添加文件（git add）并提交（git commit），这个我们后面详细说。
从远程克隆仓库则是另一回事：
git clone https://github.com/gaoshu705/qzonearchive.git cd qzonearchivegit clone不仅会把远程仓库的文件拉到本地，还会把整个提交历史、所有分支（以远程跟踪分支的形式）都完整复制下来。克隆完以后，本地会自动建立master或main分支，并跟踪远程对应的分支。
这里要特别提醒一下，git clone后面可以加参数控制克隆的深度。有些仓库历史非常庞大，比如某些大型开源项目经过多年迭代，.git目录可能有几个GB。如果你只是临时想看看代码，可以用浅克隆：
git clone --depth 1 https://github.com/gaoshu705/qzonearchive.git--depth 1表示只拉取最近一次提交的历史，这样克隆速度快很多。但浅克隆也有代价：你不能查看历史提交、不能切换到老的提交、某些需要完整历史的操作（如git log看全部记录）会受到限制。如果你要参与开发而不是随便看看，建议不要用浅克隆。
另一个常见参数是-b指定分支：
git clone -b dev https://github.com/gaoshu705/qzonearchive.git这个用法适用于默认分支不是你要的分支，或者你明确知道要拉取某个功能分支的场景。
2.2 工作区、暂存区、版本库：三个区域是理解一切命令的钥匙
在正式讲add和commit之前，必须先讲清楚Git的三个核心区域，因为后面所有命令的“为什么”，都能用这三个区域解释清楚。
- 工作区（Working Directory）：你当前能看到的、正在编辑的文件目录。这里面的文件是给人看的、给编辑器用的。
- 暂存区（Staging Area / Index）：一个中间缓冲区。
git add就是把你对工作区文件的改动“暂存”到这个区域，相当于告诉Git“我准备把这些改动打包提交”。 - 版本库（Repository / .git目录）：提交后内容真正保存的地方。
git commit会把暂存区的内容永久记录成一个提交节点，形成提交历史。
日常编辑文件的流程是：你在工作区改文件，改完觉得这部分的改动可以作为一次独立的提交，就git add放进暂存区；然后git commit把暂存区的内容固化到版本库。这个设计的好处是能精细控制提交的粒度——同一批文件改动，可以分成多次不同主题的提交，而不是一股脑全提交上去。
一个新手最容易犯的错误是：修改了文件，直接执行git commit，结果发现提示“nothing to commit, working tree clean”。原因很简单——你从来没有git add，Git根本不知道你要把哪些改动包含进这次提交。记住一个口诀：改完文件先add，add完再commit。git commit只会把暂存区里的内容提交上去，不会自动包含工作区里的新改动。
2.3 git add的进阶用法：按需提交和撤销暂存
git add最常见的用法是把所有改动加入暂存区：
git add . git add -A这两个写法的细微区别是：git add .只会添加当前目录及其子目录下的改动；git add -A会添加整个工作区所有改动，包括删除的文件。如果你在仓库根目录执行，两者没什么区别，但在子目录里执行时，行为可能不同。日常我习惯用git add -A，避免漏掉父目录里的删除操作。
更精准的用法是按文件或按目录添加：
git add src/utils/format.js git add docs/按文件添加能帮你做更细粒度的提交控制。比如你改了三个文件，其中两个文件是修bug相关的，另一个是改样式相关的，你就可以分两次添加、两次提交，让提交历史更清晰。这个习惯在团队协作中很受欢迎，因为review代码的人可以按提交逐个查看，而不用把一堆不相干的改动搅在一起。
如果需要把某个文件从暂存区撤回来，用git restore --staged：
git restore --staged src/utils/format.js注意，git restore --staged只是把文件从暂存区移回工作区，不会撤销你对文件的改动，文件内容还在，只是不再处于“已暂存”状态。如果是旧版Git，也可以用git reset HEAD <file>达到同样效果。
2.4 git commit的规范与技巧：写得清楚，后面才查得明白
git commit是把暂存区内容固化为提交记录的操作。最基础但够用的三种写法：
# 单行提交信息 git commit -m "修复登录页按钮错位问题" # 多行提交信息 git commit -m "标题" -m "具体描述" # 打开编辑器编写完整提交信息 git commit如果不加-m参数，Git会打开默认编辑器让你输入提交信息，这对写详细提交说明有帮助。
提交规范这个话题，是团队协作里绕不开的。业界最流行的提交规范是Conventional Commits，简单说就是把提交信息按“类型(范围): 描述”的格式组织：
feat: 新增用户注册功能 fix: 修复列表加载超时的问题 docs: 更新README文档 refactor: 重构登录模块代码结构 test: 补充单元测试用例 chore: 更新依赖版本我自己的体会是，提交规范的核心价值不是“好看”，而是生成changelog、定位问题版本、做代码回溯时能靠提交信息快速过滤。比如线上出了个bug，你可以用git log --oneline --grep="fix"快速找到所有修复类提交，缩小排查范围。
commit还有一个高频操作是“把当前修改追加到上一次提交”。如果刚才提交完发现漏了一个文件，或者提交信息写错了：
git add 漏掉的文件 git commit --amend--amend会创建一次新的提交，替换掉上一次提交，并且会打开编辑器让你修改提交信息。这样最终历史里只有一个提交，而不是“提交A”加“补充提交B”两个。但务必注意：--amend会改写提交历史，如果这个提交已经被推送到远程并且别人已经在基于它开发，就不要amend了。这个原则适用于所有“改写历史”的操作，后面讲到reset时还会再强调。
2.5 查看状态与对比：git status、git diff、git log
日常最常敲的命令之一就是git status。它会告诉你当前工作区处于什么状态：哪些文件修改了、哪些文件在暂存区、哪些文件还未被跟踪。建议养成一个习惯：每次提交前先跑一遍git status，确认要提交的内容确实是你想提交的，再执行add和commit。尤其是多人协作时，一个不小心把无关的临时文件提交进仓库，后面清理起来相当麻烦。
git diff用于查看具体的改动内容：
# 查看工作区与暂存区的差异（也就是未add的改动） git diff # 查看暂存区与版本库的差异（也就是已add但未commit的改动） git diff --staged这两条命令的区别人容易记混。简单理解：默认git diff比较的是“工作区 vs 暂存区”；加了--staged比较的是“暂存区 vs 版本库（上一次提交）”。一个是看还没add的，一个是看已经add但还没commit的。
git log用于查看提交历史：
# 简洁的一行一条记录 git log --oneline # 图形化展示分支合并情况 git log --graph --oneline --all # 查看某个文件的提交历史 git log --oneline -- src/utils/format.js--oneline是最实用的参数，每条提交只显示一行，包含短的提交哈希和提交信息，看历史一目了然。--graph会用ASCII字符画出分支合并的结构图，对于理解仓库的分支演化非常有帮助。--all会展示所有分支的提交记录，而不只是当前分支的。-p可以显示每次提交的具体diff内容，调试问题时很好用。
3. 分支与远程协作：团队开发的核心操作
3.1 分支的本质：一个指向提交的指针
很多人对分支有误解，觉得分支就像复制了一份代码。实际上，Git的分支本质上只是一个“指向某个提交对象的指针”。创建分支的成本极低，因为它不复制任何文件，只是新建了一个指针。而HEAD则是“你当前所在位置”的指针，指向当前分支。
常用分支操作：
# 查看本地分支（当前分支前会有*号标识） git branch # 查看所有分支，包含远程跟踪分支 git branch -a # 创建新分支（不切换） git branch feature/login # 创建并切换到新分支（最常用） git checkout -b feature/login # 或者新版写法 git switch -c feature/login # 切换分支 git checkout master git switch mastergit switch是Git 2.23引入的新命令，专门用于分支切换，和git checkout做分支切换的效果相同，但语义更清晰。git checkout还承担了“恢复文件”等职责，职责比较混杂。日常建议：想切换分支就用switch，想恢复文件或者撤销改动就用restore或checkout，职责分开后不容易出错。
这里要提醒一个常见问题：切换分支时，如果工作区有不干净（未提交）的改动，Git可能不允许切换，或者会把改动带到目标分支上。处理思路通常是先git stash暂存改动，切换完分支后再git stash pop取出。
3.2 合并分支：git merge的三种情况和fast-forward
合并分支是团队协作里最频繁的操作。最常见的合并场景是：你在feature/login分支开发完功能，要把代码合回master。
git checkout master git merge feature/logingit merge有一个重要概念叫fast-forward（快进合并）。如果当前分支（master）从分叉点之后没有任何新的提交，那么直接把master指针移动到feature分支的最新提交上即可，这就是fast-forward合并，历史是一条直线，没有额外的合并节点。但如果master在分叉后也有了新的提交，Git就必须创建一个新的合并提交，把两条分支的历史汇合起来。
合并过程可能产生冲突（conflict），提示“Automatic merge failed; fix conflicts and then commit the result”。这时不要慌，Git已经把冲突文件标出来了。打开冲突文件，你会看到类似这样的内容：
<<<<<<< HEAD 当前分支的内容 ======= 被合并分支的内容 >>>>>>> feature/login你需要手动决定保留哪部分、删除哪部分、还是两者都保留，然后保存文件。处理完所有冲突后，执行：
git add 冲突文件 git merge --continue或者直接git commit完成合并提交。这里的关键是，冲突并不可怕，它是版本控制的正常机制；真正要避免的是“看到冲突就乱删一通”，应该在理解双方改动意图的基础上做合并。
3.3 git pull与git fetch：弄清“拉的到底是什么”
git pull是把远程仓库的最新提交拉下来，并且自动合并到当前分支。它的本质是git fetch加上git merge（或git rebase）：
git fetch：只从远程下载最新的提交和分支信息到本地的远程跟踪分支（如origin/master），不会改动你的工作区。git pull：fetch之后自动执行合并操作，把远程分支合并到当前本地分支，工作区代码会发生变化。
很多人刚接触时分不清fetch和pull的区别，这里打个比方：fetch相当于你从网上下载了一个文件到下载目录，但没解压没安装；pull是下载后自动解压并安装到系统里，你的电脑环境立刻变了。
日常使用：
# 拉取并合并 git pull # 拉取并变基（后面细说） git pull --rebase # 只拉取不合并 git fetch关于pull用默认的merge还是--rebase，团队里经常有争论。简单说：如果你的本地分支有未推送的提交，而远程也有新提交，用默认merge会产生一个合并节点；用--rebase则是把你的本地提交“重新播放”到远程最新提交之上，历史是线性的，看起来更干净。我个人的偏好是git pull --rebase，因为线性历史在git log --graph里更清晰，但前提是你理解rebase的含义，并且本地没有太多复杂的合并操作需要保留。
3.4 推送与远程分支：git push的使用场景和坑
git push是把本地提交推送到远程仓库。最常用的写法：
git push origin master这个命令会把本地master分支推送到远程origin对应的master分支。如果你已经设置了上游分支（upstream），直接git push就可以。第一次推送新分支时，Git会提示你设置上游：
git push -u origin feature/login-u参数会建立本地分支和远程分支的跟踪关系，之后在这个分支上执行git pull或git push就不必再指定远程分支名了。
推送时报错是最常见的场景之一。报错“failed to push some refs”通常意味着远程分支有你本地没有的提交——可能是别人往同一个分支提交了新代码。解决办法是先把远程改动拉下来合并或变基，再重新推送。整个过程总结成标准的“提交三步走”：
git add . git commit -m "提交信息" git pull --rebase git push参考这个流程能省掉大量因推送失败引发的临时处理。pull --rebase的时候如果遇到冲突，处理方式和merge冲突一样，解决后用git add加git rebase --continue继续。
4. 撤销与回滚：git reset、git revert、git stash
4.1 git reset：回到过去，但要分清三种模式
git reset可能是Git里被误解最多的命令。它的作用是把当前分支的HEAD指针移动到某个历史提交，并同时改变暂存区和工作区的状态。具体行为取决于你选的模式：
# 软重置：只移动HEAD，保留暂存区和工作区所有改动 git reset --soft HEAD~1 # 混合重置（默认）：移动HEAD并重置暂存区，保留工作区改动 git reset --mixed HEAD~1 git reset HEAD~1 # 硬重置：移动HEAD并重置暂存区和工作区，所有改动全部丢弃 git reset --hard HEAD~1结合前面讲的三区域模型来理解：--soft只动版本库指针；--mixed动版本库加暂存区；--hard三个区域全部重置。日常最常见的场景是“提交写错了，想撤销这次提交但保留代码改动”，可以用--mixed（默认）或--soft，区别是你想不想保留暂存状态。如果只想撤销提交、让文件回到已修改未暂存的状态，用默认模式即可；如果想撤销提交后直接重新add，用--soft更快。
--hard要格外谨慎。它会把你工作区里所有未提交的改动、暂存区的改动全部抹掉，而且这些改动无法通过Git恢复。我见过太多人敲了git reset --hard才发现自己有一堆没提交的重要代码。如果你确实需要硬重置，但心里不踏实，可以先用git stash把你当前改动存起来，后续反悔了还能git stash pop找回。
基于提交哈希也能reset：
git reset --hard <commit-hash>任何没有推送过的提交都可以放心reset，但已推送的提交就不建议reset了，因为会改写历史，团队其他人拉代码时会遇到大量冲突。已推送且需要撤销的情况，推荐用下一节的git revert。
4.2 git revert：安全地“反向提交”
git revert和git reset最大的区别是：revert不会移动分支指针，而是创建一个新的提交，这个提交的内容是“撤销目标提交的改动”。它相当于把之前某个提交做的修改，再做一次反向修改，生成一个新提交。
# 撤销某个历史提交 git revert <commit-hash> # 撤销最近一次提交 git revert HEAD执行revert后，Git会自动打开编辑器让你输入提交信息，默认信息是Revert "被撤销的提交信息"。确认后，一个新的提交就生成了，历史完整保留，原来的提交依然存在，只是它的改动被新提交抵消了。
revert的适用场景是：代码已经推送到远程，甚至已经上线了，发现某个提交有问题需要撤回。此时用revert不会改写历史，团队其他人pull后自然就得到了“撤销”的效果，不会有历史不一致的问题。这是它在协作项目里替代reset的核心原因。
4.3 git stash：临时保存现场，随时回来
切换分支时工作区有未提交的改动，Git往往会阻止你切换。这时候git stash就是救命的：
# 保存当前所有改动到stash堆栈 git stash # 查看stash列表 git stash list # 恢复最近一次stash的改动，并从堆栈中移除 git stash pop # 恢复最近一次stash的改动，但保留stash记录 git stash apply # 丢弃指定stash git stash dropgit stash的原理是把你当前工作区和暂存区的改动保存到一个独立的暂存堆栈里，然后让工作区恢复到干净状态。切分支、处理后，随时git stash pop取回。
这里有个实操细节：如果在同一时间存了多个stash，默认pop会取出最近保存的那个。如果想指定取出某个，用git stash pop stash@{1}这种语法。git stash list会显示类似stash@{0}: WIP on feature/login: 3f4d5a6 提交信息的记录，stash@{0}就是索引。
stash还有一个进阶场景值得掌握：只stash已跟踪的改动，不stash新文件：
git stash --keep-index这个命令会临时保存所有未暂存的改动，但保留已经暂存的改动。适合的场景是“改了一堆文件，但我想先只提交其中一部分，剩下的暂时放一边”。
4.4 撤销工作区修改：git restore和git checkout
有时候改了半天，发现方向错了，想把某个文件恢复到上次提交的状态：
# 丢弃工作区中指定文件的改动，恢复到暂存区或版本库的状态 git restore src/utils/format.js # 旧版写法和checkout也可以 git checkout -- src/utils/format.js这条命令会把工作区中该文件的所有未提交改动直接丢弃，恢复成它最近一次提交（或暂存）的状态。注意，这个操作不可逆，一旦执行，文件里未提交的改动就找不回来了。如果不确定是否要放弃，先备份或者先用git stash。
4.5 独立修剪提交：git cherry-pick的精确打击
最后提一个非常实用但经常被归入“进阶”的命令：git cherry-pick。它可以把其他分支上的某个提交，原样“复制”到当前分支上，生成一个新的提交。
# 把另一个分支上的指定提交捡到当前分支 git cherry-pick <commit-hash>场景举例：你在feature/login上修复了一个bug，提交为a1b2c3d，但master分支现在也需要这个修复，又不想把整个feature/login合过来，这时就可以在master上git cherry-pick a1b2c3d。它和git merge的本质区别是：merge合并的是整个分支的差异，cherry-pick挑的是单个提交的改动。
如果cherry-pick遇到冲突，解决思路和其他冲突一样，改完git add后执行git cherry-pick --continue。想放弃这次pick，用git cherry-pick --abort。
5. 免密配置与效率提升：少敲几次密码，少走几步弯路
5.1 三分钟配置SSH免密提交
每次git push都要输用户名密码，对高频操作来说非常折磨。Git支持两种主流认证方式的免密：HTTPS和SSH。
HTTPS免密，用credential helper把凭证缓存到本地。Windows上一般安装Git时默认就启用了manager，会弹出窗口让你登录一次，之后就不再询问；Linux上可以用：
git config --global credential.helper storestore模式会把明文密码保存在~/.git-credentials文件里，第一次输入后就不再询问。优点是简单，缺点是明文保存，安全性稍差。如果不想明文存密码，用cache模式，把凭证缓存在内存中一段时间：
git config --global credential.helper 'cache --timeout=3600'SSH免密是更推荐的方式。原理是：本地生成一对公私钥，公钥放到Git服务器上，之后Git协议通过SSH通道传输时，服务器会用公钥验证你的身份，不再需要输入密码。配置步骤如下：
# 1. 生成密钥对，一路回车即可 ssh-keygen -t rsa -b 4096 -C "你的邮箱" # 2. 查看公钥并复制 cat ~/.ssh/id_rsa.pub然后登录你的Git托管平台（GitHub、GitLab、Gitee等），在设置里找到SSH Keys，把公钥粘贴进去保存。之后把远程地址改成SSH格式：
git remote set-url origin git@github.com:用户名/仓库名.git再执行git push，就不再需要输入密码了。这里要提醒一点：用SSH方式克隆时，远程仓库地址必须是git@...格式，而不是https://...格式。很多人在“为什么我配了SSH密钥还要输密码”的问题上卡住，原因往往就是当前远程地址还是HTTPS格式。
5.2 配置别名：把长命令缩短到两三个字母
Git命令本身不长，但组合起来就长了。可以通过别名把常用命令缩写：
git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg "log --oneline --graph --all"配置完后，git st等同于git status，git co等同于git checkout，git lg直接看图形化历史。这个配置极大提升日常效率，尤其是git lg，几乎成了我打开终端后的第一个动作。如果团队有统一的别名规范，有经验的开发者建议把别名配置同步到自己的全局配置里。
5.3 其他提升效率的小技巧
还有一个常用技巧是查看某个命令的详细帮助：
git help <command> git <command> --help遇到不确定的用法，直接用git help查官方文档，比在网上搜来历不明的命令行组合要靠谱得多。另外，git log有很多实用组合，比如查看某段时间的提交：
git log --since="2024-01-01" --until="2024-06-01" --oneline查看当前分支相对远程分支领先还是落后：
git status -sb-sb会显示当前分支和上游分支的比较情况，[ahead 2]表示本地领先两个提交，[behind 1]表示落后一个提交。这是我每天开工后必敲的第一条命令，用来快速了解有没有需要推送或拉取的提交。
6. 常见问题与排查技巧实录
6.1 “无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”
这是Windows上最常见的Git报错之一。原因有两个：要么Git没安装，要么安装了但PATH环境变量里没有包含Git的目录。
排查步骤：
- 先确认安装没安装：到“控制面板 -> 程序和功能”里看有没有“Git”。
- 如果装了但没用，去安装目录确认可执行文件位置，默认通常在
C:\Program Files\Git\cmd\git.exe。 - 在“系统属性 -> 环境变量 -> Path”里加上这个目录。
- 重新打开终端，执行
git --version确认。
如果这一切都做对了还是不行，试试重启终端或重启电脑，环境变量修改在已打开的终端里不会立即生效。
6.2 clone报错“Failed to connect”或“unable to access”
git clone时遇到网络连接问题，原因很多，最常见的是代理设置和DNS问题。排查思路：
# 查看是否配置了代理 git config --global --get http.proxy git config --global --get https.proxy # 如果有代理配置且已不需要，取消代理 git config --global --unset http.proxy git config --global --unset https.proxy注意，代理问题在国内可能需要格外谨慎，务必遵循相关法律法规，使用合法的网络环境。如果是企业内网环境，需要访问内部Git服务器，确认终端是否配置了正确的代理变量或是否在允许列表内。
6.3 推送被拒绝“failed to push some refs”
这个报错几乎每个团队协作的人都遇到过。原因就是远程分支有了你本地没有的提交，你的推送会覆盖别人的提交，Git出于安全考虑拒绝执行。
解决办法：
git pull --rebase git pushpull --rebase会把远程新提交拉下来，并把你的本地提交“垫”到远程提交之后，然后push就能成功了。如果rebase过程中冲突，逐个解决冲突后执行git add和git rebase --continue。如果处理到一半想放弃rebase，用git rebase --abort回到rebase之前的状态。
6.4 提交错了分支怎么办
场景是：你本来想在feature/login上开发，结果不小心在master上提交了好几个commit。这时候不用慌，用git cherry-pick就能解决。
# 在当前feature分支上 git cherry-pick <master分支上的提交哈希>把需要的提交“复制”到正确的分支后，再回到master分支，用git reset --hard origin/master把错误的提交从本地master分支上移除。前提是这些提交还没有推送到远程，如果已经推送了，要跟团队成员确认后再做处理。
6.5 误操作后如何“后悔”：reflog的救命用法
git reflog是我眼里Git里最被低估的命令。它记录了你本地仓库的所有HEAD移动历史，包括reset、commit、checkout、merge等操作。当你误操作了git reset --hard之后发现丢了一个提交，可以用它找回。
git reflog输出会显示类似：
a1b2c3d HEAD@{0}: reset: moving to a1b2c3d b2c3d4e HEAD@{1}: commit: 修复bug如果你想找回HEAD@{1}那个提交，只需要：
git reset --hard b2c3d4ereflog只能找回“你的HEAD曾经指向过”的提交，git reset --hard丢掉的提交只要在reflog里有记录，就还有救。这也是为什么我建议在误操作后不要马上关闭终端——reflog记录在本地，终端关不关都不影响，但越快回去找回越保险。
6.6 仓库越来越大的处理思路
仓库体积膨胀是长期项目几乎必遇的问题。常见原因有：把大文件（二进制、压缩包、模型文件）直接提交进了Git，历史里积累了多个版本；.git目录积累了大量对象文件。
处理思路：
- 使用
.gitignore从源头阻止大文件和临时文件进入仓库。 - 对已经提交的大文件，用
git rm --cached从版本库移除跟踪（但这不会清历史）。 - 如果需要清历史里的大文件，可以用
git filter-repo等工具重写历史，但这是高风险操作，必须在团队确认且所有人都已clone最新代码的情况下进行。 - 轻量方案是重新clone仓库，用
--depth 1浅克隆减小体积。
.gitignore的正确使用也值得多说一句：仓库根目录下创建.gitignore文件，里面写要忽略的模式，比如：
node_modules/ target/ *.log .DS_Store这样git add .时，匹配这些模式的文件会被自动跳过，不会进入暂存区，从源头避免了“误提交依赖目录”的尴尬。注意，.gitignore只对“未被跟踪”的文件生效，如果文件已经被Git跟踪，加入.gitignore并不会让它从仓库消失，需要先git rm --cached <file>。
7. 实操总结：把常用命令串成一套日常流程
聊了这么多细节，最后把日常开发中的Git操作串成一套完整的流程，供你直接参考。这套流程是我在多人和单人项目里都验证过的，对新人尤其友好。
场景一：接手一个新项目
git clone <远程地址> cd 项目目录 git status -sb git config user.name # 确认身份，必要时在仓库级覆盖 git config user.email场景二：开发新功能
git switch -c feature/xxx # ...写代码... git status # 查看改动 git diff # 看具体改了啥 git add <涉及文件> # 按需添加，别一股脑add . git commit -m "feat: 描述" git pull --rebase # 推送前先同步远程 git push场景三：发现上个提交写错了
git add <漏掉的文件> git commit --amend # 如果还没有推送 # 如果已经推送，用 amend 需要 force push，不建议直接操作场景四：改到一半要切分支
git stash git switch <目标分支> # ...处理完... git switch <原分支> git stash pop场景五：推上去的代码有问题
git log --oneline # 找到有问题的提交哈希 git revert <哈希> git push这套流程覆盖了绝大多数日常工作场景。说句实在话，很多人在Git上反复踩坑，不是因为某个命令不会，而是因为不理解命令背后的数据流转逻辑。理解了三区域模型，理解了fetch和merge的区别，理解了reset和revert的不同，绝大多数问题都能自己分析出答案。
以我个人的经验，学会Git最好的方式不是背命令，而是在真实的项目里反复操作、故意制造几次冲突、亲手解决掉。你可以找个测试仓库，把reset、revert、cherry-pick、stash、rebase全部实操一遍，体会每个命令对工作区、暂存区、版本库的影响。等这套“手感”建立起来以后，Git对你来说就不再是“一堆需要背的命令”，而是一套顺手的工具。到时候再看任何Git教程或者文档，都会轻松很多。
