简介这份《GIT基本命令》速查笔记面向 Git 初学者与日常开发者覆盖版本控制中最常用的操作场景帮助读者从零搭建 Git 命令使用框架并在实际协作中快速定位所需指令。资源为单个 docx 文档压缩后约 349KB便于下载后本地查阅、打印或导入笔记软件目前已有 378 人学习适合需要系统补全 Git 技能的中初级开发者。文档按真实开发流程分步整理先讲 SSH 密钥配置、HTTP/SSH 克隆仓库、git pull 远程更新再梳理 git add、commit、push 的提交链路与 git diff、status、log、reflog 等状态查看方法同时覆盖工作区、暂存区、已提交版本三种场景的还原与回退操作解释 git reset 在不同阶段的区别。分支管理部分详细讲解本地分支的创建、重命名、删除、切换与合并以及远程分支推送同步和冲突解决标准流程命令均配有说明与典型参数例如 git merge 与 git merge --no-ff 的差异。最后补充标签管理、stash 临时储藏和 rebase 变基等进阶用法条目清晰、示例具体既可作新手入门指南也可作日常开发中的命令手册。1. GIT基本命令先搞懂这套命令在解决什么GIT基本命令是每个开发者的基本功但很多人是背着命令列表去学的今天查一下git status明天复制一段git branch真到分支合并或者冲突解决的时候照样发怵。我把这套命令拆成一条完整的使用链路从安装配置、本地提交、分支合并、远程协作到出问题后的后悔药按实际工作顺序讲一遍。这套命令能解决的事情非常具体把你的代码变成有提交历史的版本库让多人在不同分支上并行开发再把各自的工作合并成一条干净的主线。适合刚接触 Git 想系统过一遍命令的初学者也适合用过图形界面工具但一碰命令行就心虚的从业者。下面直接从安装和配置开始命令会一条条给出并告诉你每次敲完应该观察什么。2. 从装到配Git 安装与首次配置的四个必调参数2.1 先看环境检查是否已安装 Git选择安装方式大部分人拿到新电脑的第一件事不是装 Git而是先敲一句git --version看看系统里有没有现成的。如果输出了版本号说明已经能用但要注意版本太老的话一些新参数比如git switch、git restore是不支持的。我一般建议至少是 2.30 以上的版本分支切换、撤销操作会顺手很多。没有安装的话常见做法是二选一用系统自带的包管理器安装或者去 Git 官网下载对应平台的安装包。包管理器适合习惯用命令装软件的人比如在 Linux 上用apt install git或在 macOS 上用 Homebrew官网安装包则适合 Windows 用户下一步下一步就能完成安装时记得把「将 Git 加入 PATH」选上否则后面在终端里找不到命令又得折腾一轮环境变量。# Debian / Ubuntu 系 sudo apt update sudo apt install git -y # macOS 且已安装 Homebrew brew install git # 安装后验证 git --version这段代码的逻辑是先更新包索引再安装避免拉到旧版本缓存最后用--version确认安装成功。如果你用的是官网安装包装完最好新开一个终端窗口再执行验证因为旧窗口的环境变量不会自动刷新这是新手最容易产生的「明明装了却提示找不到命令」的原因。2.2 首次配置三连user.name、user.email 与默认分支名Git 每次提交都会记录作者信息所以装完后的第一件事是配置身份。这里最容易翻车的是随便填了一个邮箱或没加--global参数导致提交记录里的作者信息全乱。--global表示写入当前用户的主目录配置对这台机器上所有仓库生效不加则只对当前仓库生效适合公司项目用公司邮箱、自己开源项目用私人邮箱的场景。git config --global user.name 你的名字 git config --global user.email youexample.com git config --global init.defaultBranch main第三个参数的用处很多人会忽略。以前新仓库默认分支叫master现在业内普遍用main如果不在初始化之前设好每次git init后还得手动改一次分支名比较麻烦。设置完可以用git config --global --list查看全部配置确认三项都写进去了再继续。2.3 配置生效顺序system、global、local 到底谁说了算Git 配置分三个层级系统级system、全局级global、仓库级local。生效顺序是仓库级覆盖全局级全局级覆盖系统级。也就是说同一个配置项在三处都设置了离你当前仓库最近的那个值最终生效。这个特性特别适合处理「公司仓库要用公司邮箱自己的项目用个人邮箱」这种需求。# 查看某条配置是从哪个文件来的 git config --list --show-origin # 只给当前仓库单独设置邮箱 git config --local user.email workcompany.com当你想排查为什么配置不生效时--show-origin会直接告诉你每条配置写在哪个文件里。我在实际工作中遇到过很多次「明明改了 user.email 怎么提交记录还是旧邮箱」的情况最后都是因为全局配置里还有一个旧值没有被 local 值覆盖。另外如果你习惯用 VS Code 之类的编辑器建议顺手把提交信息的默认编辑器换成它免得被 vim 卡住不知道怎么退出。设置命令并不复杂但能帮你省掉一次「提交信息写一半人卡在 vim 里」的糟糕体验。3. 本地提交闭环git init 到 git commit 的八个高频命令3.1 理解三个区工作区、暂存区与 HEAD用 Git 管理一个项目脑子里先要有三区模型工作区是你能直接看到的文件暂存区是存放「准备提交」改动的地方HEAD 是最近一次提交的指针。大部分命令都是在让文件在这三个区域之间移动理解了这一点git add、git commit的逻辑就再也忘不掉了。# 初始化仓库 git init # 查看当前状态 git statusgit init会在当前目录生成一个隐藏的.git文件夹这个文件夹就是仓库本体别去手动改里面的东西。git status则是最常用的体检命令它会用不同的符号告诉你文件的处境??表示未跟踪的新文件M表示已修改A表示已加入暂存区。刚初始化完的仓库里执行git status看到的一堆??就是还没被 Git 管理的文件下一步就要用git add把它们纳入管理。3.2 git add 的两种姿势与暂存区的撤销git add的常见姿势有两种git add .把当前目录所有改动加入暂存区适合改动比较集中的时候git add 具体文件路径只选择某些文件加入适合不想把临时配置文件或者日志文件混进来的场景。我常用的命令里其实git add -A用得更频繁因为它连删除文件的操作也一并记录进去了而git add .在某些旧版本里对删除操作的敏感度不同容易漏掉删除记录。# 添加所有改动新增、修改、删除 git add -A # 只添加指定文件 git add src/utils/format.js # 把某个文件从暂存区撤回但保留工作区的修改 git restore --staged src/utils/format.js第三行命令是「后悔药」的一种把文件从暂存区挪回工作区内容不会被改动只是不再参与下一次提交。注意git restore --staged是 2.23 版本之后出现的用法老版本用的是git reset HEAD file如果你所在的仓库版本太老后者的兼容性更好。3.3 git commit 的参数写提交信息是门细活git commit不是简单地把暂存区内容拍一张快照。它要求你给这次提交写一段说明这段说明会进入提交历史成为将来回溯的依据。写得好的提交信息是「改了什么事、为什么改」而不是「修改了一些文件」这种废话。我个人常用的格式是简洁一行复杂改动就加-m再写一段把原因交代清楚。# 普通提交 git commit -m feat: 增加用户登录接口 # 把已跟踪文件的修改直接提交跳过 add 步骤新文件不会被包含 git commit -am fix: 修复登录超时问题 # 修改上一次提交的提交信息还没 push 的情况下 git commit --amend -m feat: 增加用户登录接口并补充单元测试-a参数的作用是自动把已跟踪的改动加进暂存区再提交但新文件必须手动git add这个边界很多人踩过。--amend则是修改最近一次提交的提交信息也可以把遗漏的小改动并入上一个提交注意本地提交还没推送到远程时才能放心用推送过了就别改了否则会造成历史分叉。3.4 git log 与 git diff看清历史与改动的两个利器提交只有自己能看懂还不行得能查验历史。git log就是查看提交历史的入口但默认输出太长太难扫我一般会加上参数只看精简信息git diff则是看具体改动的命令它默认比较的是工作区和暂存区之间的差异如果加了--cached比较的则是暂存区和 HEAD 之间的差异。# 一行显示一条提交记录并画出分支拓扑 git log --oneline --graph --all # 查看当前工作区改动统计 git diff --stat # 查看具体某个文件的改动 git diff src/utils/format.js # 查看暂存区和 HEAD 的差异即将提交的内容 git diff --cached--stat只显示每个文件改了多少行适合快速扫一遍改动范围不加参数直接看某个文件会输出带和-标记的行级差异这是 review 代码时最常用的操作。--graph分支拓扑能直观看到分叉和合并的路径对理解后面要讲的分支合并很有帮助。4. Git分支合并从 git branch 到 merge 的冲突解决4.1 分支的创建、切换与删除分支是 Git 最核心的工作模式它的本质是一个指向某个提交的可移动指针。创建分支的开销极低所以很多团队的习惯是「每个功能一个分支」做完合并进主干再删掉。命令行下分支操作有几条最常用先记住创建和切换组合命令git checkout -b它能一步完成「创建并切换」比分开敲git branch和git checkout效率高不少。# 基于当前 HEAD 创建新分支并切换过去 git checkout -b feature/login # 查看所有本地分支当前分支名前有星号 git branch # 切换回主分支 git checkout main # 合并完成后删掉特性分支 git branch -d feature/logingit branch不带参数只列出本地分支列表加-r能看远程分支加-a看所有分支。-d是安全删除只有分支上的提交已经被合并进其他分支才会成功如果强行要删掉一个没合并的分支得用大小写的-D这个操作没有后悔药删除前最好先确认分支上的提交是不是真的不要了。4.2 merge 的两种合并姿势fast-forward 与 --no-ff分支合并最常见的命令是git merge branch它把指定分支的提交历史合并进当前分支。这里有一个很多人没意识到的区别如果当前分支比目标分支新而且两个分支没有分叉Git 默认会走 fast-forward 合并直接把指针往前移不产生新的合并提交如果分支已经分叉了Git 会生成一个合并提交把两条历史的改动揉在一起。# 切换到主分支后合并特性分支 git checkout main git merge feature/login # 强制不打 fast-forward保留一个合并提交 git merge --no-ff feature/login # 取消正在进行的合并还没解决完冲突时 git merge --abortfast-forward 的问题在于历史看起来是一条直线看不出「这是一个功能分支被并入」的边界--no-ff则强制留下一个合并提交记录这次合并的上下文。团队协作一般更推荐--no-ff因为能保留功能开发的完整脉络。merge --abort是冲突解决到一半发现自己搞乱了时的逃生门它能恢复到合并之前的状态。4.3 冲突标记与手动解决流程合并冲突是 Git 使用中最让新手头皮发麻的场景但它其实并不可怕本质就是两个分支改了同一个文件的同一段代码Git 不知道哪边对于是把决定权交给你。发生冲突时打开文件会看到类似下面这种标记。 HEAD 当前分支的代码 另一条分支的代码 feature/login和之间是当前分支HEAD的内容和之间是被合并分支的内容。你要做的不是惧怕这些标记而是手动核对两边的代码决定保留哪一边、还是两边都保留、还是改成一份融合后的新代码然后把标记行删掉最后git add这个文件再git commit即可完成一次冲突解决。# 查看哪些文件存在冲突 git status # 手动改完冲突文件后标记为已解决 git add src/pages/login.vue # 完成合并提交 git commit -m merge: 合并登录功能分支按我的习惯冲突解决过程通常会打开另一个终端用git diff --name-only --diff-filterU列出所有冲突文件清单避免漏掉哪个文件没处理导致git status一直提示还有未解决的冲突。建议一开始就养成「改一个、add 一个」的习惯全改完再一次性提交别把所有文件攒到最后才处理。4.4 分支开发常见误用别在主分支上直接改把分支用好最重要的习惯只有一条不要在main主分支上直接改代码。很多团队的分支规范是「主分支只接受合并不接受直接提交」因为主分支是所有人共享的基础线你直接在上边提交一个半成品别人拉下来就是半成品线上出问题都难排查。我刚开使用 Git 的时候犯过这个错改完忘了切分支直接在 main 上提交后来要把那个提交挪走花了不少功夫。正确的流程是新建功能分支、在功能分支上提交若干次、切回 main 拉取最新代码、合并功能分支、推送。日常操作中我最常用的一条组合命令是git checkout -b快速开分支配合git branch -d在合并后及时清理。这套流程熟练之后你的提交历史会越来越整齐每个功能都有清晰边界。5. 远程协作与避坑SSH 认证失败与五条高频翻车记录5.1 git remote 与 push/pull/clone 的最小协作闭环本地仓库要跟其他人协作就得挂上远程仓库。git remote的作用是给远程地址起个别名业界默认叫origingit clone则是把一个远程仓库完整复制到本地顺便把origin配置好。无论你是纯命令行操作还是在 IDE 里新建项目拉取 git 仓库本质都是 clone 加 checkout 这套流程。# 克隆远程仓库到当前目录 git clone gitexample.com:team/project.git # 已有仓库时添加远程地址 git remote add origin gitexample.com:team/project.git # 首次推送并设置上游分支 git push -u origin main # 推送当前分支 git push # 拉取远程改动并合并到当前分支 git pull-u的作用是一次性把分支的上游关系记下来之后在这条分支上直接git push或git pull就不用再敲远程名和分支名了。pull实际上是两步操作的组合先fetch拉取远程不改变本地工作区的数据再merge合并到当前分支。如果你不想让自动合并产生意外可以改成git pull --rebase这个后面会专门讲。5.2 排查一git SSH 认证失败Permission denied怎么救SSH 认证失败是最多人来问的排查问题报错信息通常是Permission denied (publickey)。第一反应不要慌按顺序做三件事确认远程地址用的是 SSH 协议还是 HTTPS 协议检查本地是否存在可用的私钥再确认 SSH agent 是否已经加载了私钥。# 查看远程地址用的是哪种协议 git remote -v # 生成新的 SSH 密钥对按提示设置路径和密码短语 ssh-keygen -t ed25519 -C youexample.com # 启动 ssh-agent 并加载私钥 eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519 # 测试与托管平台的认证连接 ssh -T gitexample.com常见的失败原因有三层。其一远程地址写成了https://开头那你再怎么调密钥都没用得改成git开头的 SSH 格式。其二密钥文件权限不对私钥对当前用户没有读写权限时会直接被拒绝chmod 600 ~/.ssh/id_ed25519可以解决。其三ssh-agent 没加载私钥或者加载了但平台端没有登记对应的公钥需要打开托管平台把~/.ssh/id_ed25519.pub的内容贴到 SSH 公钥设置里。测试连接出现欢迎提示信息即代表成功如果还是 Permission denied重点检查公钥有没有正确登记、私钥路径有没有填对。5.3 排查二换行符把全仓库搞出几千个差异现象明明只改了一个文件git status却显示几百个文件全是 modifiedgit diff看过去全是整行替换。原因几乎都是换行符问题——Windows 下文件默认用 CRLF 结尾Linux/macOS 用 LFGit 在提交时会按配置决定是否转换。转换规则没设好每次 checkout 都会把仓库里所有文件的行尾改一遍。# 让 Git 提交时自动转 LF检出时按平台自动处理 git config --global core.autocrlf true # 更稳妥的做法提交时转 LF检出不转换 git config --global core.autocrlf input # 根因治理用 .gitattributes 固定规则 echo * textauto .gitattributes git add .gitattributes git commit -m chore: 固定换行符规则core.autocrlf true适合 Windows 用户提交时转成 LF检出时转成 CRLFinput适合 Linux/macOS 用户提交时转 LF检出时保留原样。最推荐的做法是仓库根目录维护一份.gitattributes把换行规则写进去所有协作者不论用什么系统都会被同一套规则约束一劳永逸。如果仓库已经被污染先提交.gitattributes再把当前工作区文件重新规范化一次这个后续可以单独处理。5.4 排查三.gitignore 明明写了却不生效现象在.gitignore里加了node_modules/可是git status还是能看到相关文件甚至执行过git add也没用。原因是一个关键概念没到位.gitignore只对「未被跟踪的文件」有效如果某个文件已经被 Git 跟踪了之后再把它写进.gitignore是不会生效的。最常见的翻车场景就是初始化项目时把所有文件一股脑 add 并 commit 了然后才想起来要忽略某些目录。# 把已被跟踪的目录从版本库中移除但保留本地文件 git rm -r --cached node_modules # 重新提交 .gitignore 和移除记录 git commit -m chore: 移除已被误跟踪的 node_modules # 验证是否已不再跟踪 git status--cached的作用是只把文件从暂存索引里删除不碰你磁盘上的实际内容本地文件还在只是版本库不再跟踪它。处理完之后再用git status确认发现 node_modules 不再出现在列表里就说明成功了。这个操作不会丢失数据但会被记录为一次删除提交推送到远程后其他人也不会再跟踪这些文件。5.5 排查四合并冲突后强推导致历史混乱现象几个人协作时有人为了省事直接执行git push --force把别人的提交从远程历史里抹掉了然后其他人拉代码时各种分叉、各种丢失提交再想找回来只能去 reflog 里翻。原因是用强推覆盖了远端历史这属于并发协作里最危险的操作之一尤其在本地的历史不是基于最新远程 HEAD 时会直接丢掉别人推到远程的提交。解决方式不是禁止强推而是给强推加条件以及优先用 rebase 方式拉取远程改动。# 拉取远程改动并用 rebase 方式变基到本地提交之上 git pull --rebase # 绝对需要强推时用 --force-with-lease 做安全检查 git push --force-with-leasegit pull --rebase会先把本地未推送的提交暂时拿下来把远程的新提交应用到当前分支再把本地提交重新放回去这样历史是线性的不会有 merge 提交。--force-with-lease比--force安全得多它只在远程分支还是你上次同步时的状态时才允许强推如果远程有了别人新推的提交命令会直接拒绝避免覆盖。这条排查要传达的核心习惯是任何时候不确定远程状态先git pull --rebase再 push别想着用--force省事。6. 后悔药与进阶边界git reset、stash 与 rebase 的正确打开方式6.1 git reset软、硬、混合三种模式怎么选提交写错了、不需要的改动被混进来了这些都是家常便饭git reset就是原地后悔药。它的核心是移动 HEAD 指针并选择是否重建暂存区和工作区三种模式对应三个选择维度。模式HEAD 移动暂存区工作区典型场景--soft是保留保留把多次提交合并成一次--mixed默认是清空保留撤销提交但保留改动重新 add--hard是清空清空彻底丢弃改动回到某个提交# 撤销最近一次提交保留改动在暂存区 git reset --soft HEAD~1 # 撤销最近一次提交保留改动在工作区 git reset HEAD~1 # 彻底回到某个提交丢弃之后的所有改动 git reset --hard commit-hash--soft最常用在「连续提交的两个 commit 其实是一个功能想合并成一个」reset 掉一次然后重新 commit 即可。--hard是最危险的操作因为工作区文件会被真的改掉唯一找回路径是靠git reflog找回旧提交哈希但时间久了很容易找错。6.2 git stash把半成品收起来再恢复经常出现这种情况在 feature 分支上改到一半突然要回主分支修一个紧急 bug但当前半成品不想提交也不想丢。git stash就是为此设计的把工作区和暂存区的改动临时存起来让工作区变成干净状态办完事再取回来。# 临时保存当前改动 git stash push -m 登录功能开发中 # 查看保存的列表 git stash list # 恢复最近一次保存并从列表中移除 git stash popstash push -m给备份加一段备注方便恢复时辨认。pop会套用最近的 stash 并删除记录如果只想恢复但还想保留备份用git stash apply。这个命令不改变提交历史纯粹是工作区的临时收纳箱边界在于 stash 是「栈式」结构恢复顺序是后进先出别指望在里面翻出旧修改后还在原来的位置。6.3 用 rebase 整理提交前先确认你还不是远程分支的常客rebase和merge的区别在于rebase会把你的提交一个个取下来重新应用改写下它们的哈希值历史确实变线性了但代价是「改写历史」。功能分支合并回主分支之前在本地用 rebase 整理提交顺序或压缩提交是可以的但主分支这种多人共用的分支绝对不要去 rebase否则所有协作者都会因为哈希不匹配而陷入痛苦的分叉。我的个人习惯是功能分支开发结束准备合并前先git rebase main把主分支的新提交「变基」进我的分支解决掉冲突后再回 main 执行git merge --no-ff。这样主分支历史干净功能分支的提交也确实是基于最新主干开发的。有一次我偷懒在共用分支上rebase并强推害得同事多花了一下午处理分叉后来我就把这条规则刻进了脑子共用分支只merge不rebase自己的分支随意。这趟命令走下来你手里的 Git 已经足够应付中小团队日常开发了。无论以后再遇到什么玄学问题先记住一条任何危险操作之前备份分支名或提交哈希留好后悔药。希望帮到你。本文还有配套的精品资源点击获取