简介面向 Git 初学者与日常协作开发者的命令速查资源系统梳理 SSH 密钥配置、仓库克隆与更新、代码提交与还原、本地及远程分支管理、冲突解决、标签操作等核心场景并延伸至 stash 工作现场暂存、rebase 分支整理等进阶用法无论是个人项目还是团队协作都能快速定位所需操作。覆盖 git clone、commit、reset、merge、rebase 等高频命令的完整语法与适用场景适合作为随查随用的操作手册。压缩包内仅含 1 个 docx 文档体积 349KB内容以分节速查表形式呈现便于按需检索对应命令。目前已有 378 人学习文档针对工作区改动、已暂存、已提交未推送等不同状态分别给出还原方案并列出解决冲突的标准流程可帮助读者快速摆脱误提交、冲突无从下手等常见问题提升日常开发与团队协作的效率。1. 面对 Git 命令清单先从使用顺序入手而不是背参数Git 基本命令看起来散其实有一条清晰的线配置密钥、克隆代码、提交推送、分支合并、冲突解决、标签发布每一步都在回答一个真实协作问题。这份资源不是把所有 Git 命令按字母排列而是按照一个开发者的实际操作路径整理的从 SSH 配置开始一直覆盖到 reset、rebase、stash 和分支策略。它适合两类人一类是刚接触版本控制的开发者想快速拿到能跑通全流程的命令另一类是已经用了很久但偶尔在还原文件、处理远程分支时犹豫的熟手翻这类清单是为了确认参数的边界和副作用。接下来按这条链路逐个拆开把命令能做什么、不能做什么、以及容易翻车的位置讲清楚。2. 从 SSH 到首次克隆先把本地服务器身份打通再动手2.1 生成 SSH 密钥并完成连接测试初次接触 Git 服务器第一个动作不是 clone而是确认服务器认你的身份。通过 HTTP 协议克隆通常需要每次输入账号密码而配置 SSH 之后推送和拉取都能走密钥认证省掉重复输入。常见做法是执行 ssh-keygen 生成一对密钥公钥放到服务器上私钥留在本地。ssh-keygen -t rsa -C 你的邮箱执行后会提示设置密码直接三次回车表示不设密码。-t rsa指定生成 RSA 算法密钥-C后面追加一个注释通常写邮箱用于标识这把密钥的归属不影响认证结果。生成的文件默认在用户目录下的.ssh文件夹中私钥是id_rsa公钥是id_rsa.pub。这里有个很容易踩的细节需要复制到远程仓库的是公钥id_rsa.pub里的内容不是私钥。打开公钥文件复制全部字符粘贴到远端仓库后台的 SSH key 配置区即可。ssh git服务器IP这条命令用于测试 SSH 连接。首次连接时终端会提示确认服务器指纹输入yes后回车。如果返回一段欢迎信息并且能看到该用户名对应的说明说明密钥配置生效。常见的失败情形是提示权限被拒绝Permission denied这时优先检查公钥是否完整复制、本地私钥文件权限是否过宽。ls -la ~/.ssh确认两个文件存在后用ssh-add -l检查私钥是否被 SSH agent 加载必要时执行ssh-add ~/.ssh/id_rsa手动添加。2.2 clone 与 pull 的协议差异及分支参数配置好 SSH 后克隆仓库就分为两种方式。HTTP 克隆适合服务器还没配置 SSH key 的临时场景SSH 克隆适合日常使用。git clone http://服务器IP:端口/组名/仓库名.git git clone git服务器IP:组名/仓库名.gitHTTP 方式会要求输入远程账号密码每次推送拉取都可能弹认证SSH 方式只要密钥配置有效后续操作不再有交互式认证。端口号只出现在 HTTP 地址中SSH 默认走 22 端口若服务器修改过 SSH 端口需要在地址里显式带端口例如ssh -p 端口 git服务器IP但 clone 地址通常写为ssh://git服务器IP:端口/组名/仓库名.git这种显式形式。两种协议的差异更推荐用表格记录对比项HTTP 克隆SSH 克隆认证频率每次操作可能认证配置后免密地址构成包含 IP 与端口用户名加 IP适用场景临时拉取长期开发推送防火墙友好度通常好于 SSH依赖 22 端口开放拉取远程更新时命令需要带分支名git pull origin 分支名origin是远程仓库的默认别名分支名指定拉取哪个分支。执行 pull 前本地工作区最好保持干净如果本地有未提交的修改并且这些修改涉及的文件刚好与远程更新冲突pull 会报错并要求你先处理本地改动。所以我的习惯是pull 之前先git status看一眼有改动就先提交或临时 stash再执行更新。3. 提交工作流diff、add、commit、push 的顺序不能乱3.1 用 diff 精确确认改动内容提交代码前最忌讳的事情是凭印象写提交说明。先看改了什么再决定哪些文件参与本次提交这条纪律能避免把调试代码夹带进版本库。git diff不加参数的git diff比较的是工作目录与暂存区域之间的差异也就是你已经修改但还没执行git add的内容。换句话说它回答的问题是“我改了哪些文件、具体改了哪些行”。如果你想看已经git add过但还没提交的内容用的是另一组参数git diff --cached git diff --staged这两条命令等价。它们的比较对象是暂存区域与上一次提交HEAD之间的差异能看到已被标记为待提交的改动。这个区分很容易混淆记住一个判断逻辑还没 add 的改动看git diff已经 add 的改动看git diff --cached两者都想知道时直接执行git diff HEAD这条命令忽略暂存区状态直接对比工作目录与最近一次提交不管改动的文件有没有git add都会展示出来。日常开发中我一般用git diff快速验证手头修改用git diff --stat只看文件变更统计避免大段输出干扰判断。提交后想核对这次提交包含了哪些文件、每个文件增删了多少行可以配合git log --stat -n查看最近几条提交的统计信息。3.2 暂存、提交与推送三个独立步骤的边界git add 文件名 git commit -m 提交说明 git push origin 分支名这三条命令执行的是三个不同阶段的操作。git add把文件放进暂存区git commit把暂存区的内容固化成版本库中的一个新提交git push把本地新提交推送到远程分支。很多人第一次接触 Git 时会误以为 commit 之后远程就更新了实际上 commit 只发生在本地没有 push 之前远程完全察觉不到。git commit -a -m 注释是一个快捷方式它可以跳过显式git add直接提交所有已跟踪文件的改动。但这里有边界-a参数只对 Git 已经跟踪的文件有效新增的未跟踪文件untracked file不会自动加入提交。所以我在需要一次性提交多个已跟踪文件时才会用git commit -a涉及新文件时还是老老实实分两步。常见做法是在提交前执行git status确认暂存区内容避免把不想提交的文件混进去。git status的输出会列出三个区域的信息尚未暂存的修改、已暂存可提交的修改、未跟踪的新文件。提交信息本身也值得养成习惯尽量写清楚“做了什么”不要只写“修改文件”因为git log记录下来的信息是要留给未来排查问题用的。3.3 push 之前先考虑要不要 pullgit push origin 分支名推送时最常见的报错是“推送被拒绝远程包含本地没有的提交”。这个现象说明远程分支上存在其他同事推送的新的提交而你的本地分支基于旧节点直接推会覆盖他人成果Git 出于安全考虑直接拒绝。解决路径很清晰先git pull origin 分支名把远程提交拉下来再重新提交你的本地修改最后 push。如果 pull 过程中出现代码冲突Git 会标记冲突文件手动修复后依次执行git add、git commit再 push。养成先 pull 再 push 的习惯尤其是多人共用一个分支时这个顺序能减少大量冲突修复时间。提交历史用的查看命令也在这里一起说明git log默认按时间倒序列出全部提交按q退出git log --prettyoneline会把每个提交压缩成一行只显示哈希值和提交说明git log --graph --prettyoneline --abbrev-commit能以图形方式展示分支的合并路径排查分支关系时最有用。4. 还原与重置checkout、reset、revert 各自能吃到哪一步4.1 工作区文件还原checkout 的不可逆风险git checkout -- 文件名这条命令把工作区中的指定文件还原到最近一次提交的状态。适用场景是你改了某个文件但改乱了想放弃改动回到修改前。需要注意这个操作会直接丢弃工作区中未暂存的修改而且被丢弃的内容无法通过 Git 恢复。执行前先问问自己这个改动真的不要了吗有个保守的检查办法先执行git diff 文件名查看改动内容确认无误后再 checkout。如果改动已经git add进了暂存区情况会复杂一些因为上面的 checkout 命令只处理工作区与提交版本之间的差异不会动暂存区内容。这时候需要先让暂存区释放文件再回到工作区还原git reset HEAD 文件名 git checkout -- 文件名git reset HEAD 文件名的作用是把暂存区中的该文件移除让它回到“已修改但未暂存”的状态文件内容本身不变。之后再执行 checkout 才能把工作区内容切回提交版本。这就是还原文件时最容易被绕晕的两步流程很多初学者只执行了 checkout发现文件没有变化就是因为暂存区还占着一个副本。4.2 reset 的三个模式soft、mixed、hardgit reset是 Git 里功能最多也最危险的一组命令它本质上是移动 HEAD 指针的位置。资源文档中提到三种模式--soft、--mixed、--hard它们的差异在于移动指针的同时对暂存区和工作区的处理力度不同。git reset --soft HEAD~1 git reset --mixed HEAD~1 git reset --hard HEAD~1--soft只回退提交记录暂存区和工作区的文件内容都不变。也就是说上一次 commit 的内容会回到暂存区再执行一次git commit就能创建新的提交这个模式常用于“刚才提交错误地包含了文件想重新提交”。--mixed是默认模式回退提交记录的同时清空暂存区但工作区文件内容保留修改会变成未暂存状态。--hard最激进提交记录、暂存区、工作区全部回退到指定版本工作区的源码会直接变成旧版本内容。这三个模式的记忆方式可以简化为soft 只动指针mixed 动指针和暂存区hard 三样全动。模式HEAD 指针暂存区工作区--soft回退保留保留--mixed回退清空保留--hard回退清空清空实际使用中git reset --hard是最需要谨慎的一条命令。执行后本地源码立即变为目标版本所有在工作区中的未提交改动都会消失。但它并不是完全没救git reflog是 Git 的后悔药它记录了 HEAD 指针移动的历史包括被 reset 丢弃的提交哈希值。git refloggit reflog会列出最近所有 HEAD 变动记录每一行都包含提交哈希和操作描述。假设你执行了git reset --hard 版本号想回到某个老版本发现回错了想在刚才那个新版本上继续开发直接去 reflog 里找到旧提交的哈希值再执行一次git reset --hard 旧哈希就能跳回来。这是 Git 工作中最实用的恢复技巧没有之一。4.3 HEAD^ 与 HEAD~1 的区别和正确用法git reset --hard HEAD^和git reset --hard HEAD~1都能回退到上一个提交但二者在语义上存在细微差别。HEAD^表示当前提交的父提交HEAD~1表示往上数 1 个提交。在简单线性历史上两者等价一旦涉及合并提交merge commit^指的是第一个父提交而~是沿着第一父提交链向上走。git reset --hard HEAD^ git reset --hard HEAD~3HEAD~3表示向上回退 3 个提交。这里有一个资源文档里容易误导人的地方原文写的是向前回退到第 3 个版本实际语义是从当前 HEAD 往回数 3 个版本不是前进。执行前先跑git log --oneline确认目标提交的位置。如果已经 push 到远程分支reset 本地版本后会和远程产生分叉下次 push 会被拒绝这时要评估是否真的需要重写公共历史。团队共享分支上应避免使用 reset 回退改用git revert创建反向提交。git revert HEAD会生成一个新提交这个提交的内容是上一次提交的反向操作等于用一次新提交抵消旧提交的改动。它的好处是不会移动历史指针适合已经推送到远程的分支。资源文档中的 reset 和 revert 各有适用边界本地未推送的提交用 reset已推送的公共提交用 revert。5. 分支管理本地分支、远程分支与合并的完整生命周期5.1 创建、切换与删除本地分支分支操作是 Git 协作的核心。首先从已有分支创建新分支git branch 分支名 master分支名是新分支的名字master是起点。这条命令只创建不切换当前所在分支不变。想要创建并立刻切换过去用checkout -b一步到位git checkout -b 分支名-b参数的含义是创建分支后立即切换等效于先执行git branch 分支名再执行git checkout 分支名。基于远程分支创建本地分支的常见写法是git checkout -b dev origin/dev这条命令会创建名为 dev 的本地分支并跟踪远程的 origin/dev之后的 pull 和 push 会默认关联远程 dev 分支。重命名分支用git branch -m 旧名 新名注意重命名前最好确认没有其他人基于旧分支名做操作因为改名只影响本地远程分支名不会自动跟随。删除分支命令git branch -d 分支名 git branch -D 分支名-d只允许删除已合并的分支如果分支还有未被合并的提交Git 会拒绝并提示。-D是强制删除不检查合并状态。这里有一个处理技巧分支开发完并确认合并后用-d是安全的如果分支上的实验代码不想保留直接-D但删除后该分支独有的提交会从分支引用中消失只能靠 reflog 或哈希值找回。5.2 合并策略fast-forward 与 --no-ff 的分歧分支开发的最终目标通常是合并回主分支先理解合并的两种方式。git checkout master git merge 分支名默认情况下Git 执行的是快进式合并fast-forward merge。它的条件是主分支没有产生新的提交此时 Git 直接把 master 指针移动到分支名指向的提交上结果是历史保持线性不会生成合并节点。git merge --no-ff 分支名--no-ff会强制产生一次正常合并在 master 分支上生成一个新的合并提交节点哪怕主分支可以直接快进。为什么团队策略经常推荐--no-ff因为合并节点能保留“这条分支曾在某个时间点被合入主线”的记录后续用git log --graph查看时分支合并的边界清晰可见。默认的快进式合并会把分支历史压平看不出来哪些提交属于一次功能开发。合并过程中如果发生冲突Git 会列出冲突文件。处理流程是打开冲突文件找到、、标记的冲突区域手动保留需要的代码删除标记符号然后执行git add 冲突文件 git commit -m 解决合并冲突注意解决冲突后的提交不需要再带什么特殊参数直接正常提交即可。整个过程中git status会提示“未合并的路径”等状态按提示逐个文件处理完再提交不要漏掉未解决的文件。5.3 远程分支创建、删除与本地同步把本地分支推送到远程Git 会用分支名在远程新建同名分支git push origin 分支名如果远程已有同名分支这就是一次普通推送如果远程没有则自动创建。删除远程分支使用git push origin --delete 分支名这条命令会删除远程对应的分支但本地分支仍然保留需要的话用前面的git branch -d单独处理。查看远程分支列表使用git branch -a git branch -rgit branch -a显示本地加远程的所有分支git branch -r只显示远程分支。资源文档中提到远程分支显示为红色这是终端默认配色不同 Git 配置文件可能表现不同不用作为判断依据。本地分支列表和远程分支的对应关系偶尔会失真比如其他同事删除了远程分支本地执行git branch -a仍能看到过期的远程分支记录。解决办法是同步git fetch origin --prune--prune参数会在抓取远程更新的同时清理本地已经失效的远程分支引用。它不会动工作区和当前分支的内容是安全的常规维护命令。资源文档中提到的远程分支管理顺序建议是先 fetch 同步再检查分支列表最后 push 新分支或删除旧分支。6. 分支协作高频问题排查冲突、rebase、stash、reset 的连带事故6.1 合并冲突与 rebase 冲突的处理顺序不同现象执行git merge develop时终端提示“自动合并失败请修复冲突后提交”执行git rebase origin/master时同样提示冲突但后续步骤不一样。原因merge 产生的冲突需要你手动修复文件后执行 add 和 commit 来结束这次合并rebase 产生的冲突在修复文件后只需 add不需要 commit而是用git rebase --continue让 rebase 流程继续应用后续补丁。git add 冲突文件 git merge --continuemerge 场景下修复冲突并 add 后可以用git merge --continue完成提交也可以用git commit完成。rebase 场景下git add 冲突文件 git rebase --continue如果 rebase 过程中发现思路不对想退出执行git rebase --abort分支会回到 rebase 开始前的状态。这个区别是新人最容易卡住的地方rebase 冲突修复后直接 commit 会破坏 rebase 的连续应用机制正确动作是 add 后 continue。6.2 reset --hard 后找不到提交现象执行git reset --hard 版本号回退到旧版本过了几个小时发现还需要旧版本之后的某个提交但git log已经看不到那个提交了。原因git log只显示当前 HEAD 能追溯到的提交记录hard reset 移动了 HEAD原分支上的提交丢失了引用变相成了“孤儿提交”。解决用git reflog查看 HEAD 的完整变动历史找到丢失提交的哈希值然后执行git reset --hard 哈希值跳回去。git refloggit reflog的输出会包含每次 HEAD 移动前的位置和操作记录。需要注意的是 reflog 记录的是本地操作不会随 push 上传所以它只能在当前仓库内找回内容。如果这个提交从未 push 过、而本机仓库又被清理过那才是真正丢失。所以遇到 hard reset 前我会先执行git log --oneline记录当前哈希相当于给未来留一条退路。6.3 stash 后现场丢失现象执行git stash储藏了未提交的改动然后git stash list看不到任何记录或者git stash pop弹出时报冲突导致原本的改动无法直接拿回。原因git stash list为空大概率是之前弹出了储藏并成功合并储藏被自动删除git stash pop报冲突是因为工作区当前状态与储藏内容基于的提交版本不一致Git 无法自动合并。解决如果储藏还在但 pop 冲突先不要继续操作手动修复冲突文件处理完后执行git stash drop丢弃已经弹出的储藏记录避免留下过期引用。如果储藏不在 list 里去 reflog 里找临时提交哈希。stash 本质上是用临时提交保存现场git fsck --lost-found也能找回一些孤立对象但操作成本较高。git stash pop git stash applypop会直接恢复并且删除储藏记录apply恢复但保留记录。资源文档中的建议是不确定现场是否能干净恢复时优先用apply确认无误后手动drop。这个习惯能防止一次性 pop 把改动直接写到工作区然后弹出冲突导致现场与储藏记录都不完整。6.4 rebase 后 push 被拒绝现象本地分支执行git rebase origin/master后提交历史重写执行git push origin 分支名被拒绝提示远程包含本地不存在的提交。原因rebase 会为当前分支生成全新的提交对象原本已推送的提交被替代远程分支与本地分支历史分叉Git 拒绝非快进式推送。解决对于尚未推送到远程的本地分支rebase 后 push 没有阻碍对于已经推送到远程、且分支只有你自己在使用的场景常见做法是强制推送但后续其他人若基于旧提交继续开发会被强制覆盖。更稳妥的方案是--force-with-lease它会检查远程引用是否仍在你上次 fetch 的状态是才允许覆盖否则拒绝给协作分支留一层保底。git push --force-with-lease origin 分支名在团队分支上我的原则是尽量不重写公共历史rebase 只用于本地分支整理需要同步远程时优先 merge。7. log、diff 与 tag 的组合版本定位与发布的实操技巧分支理顺之后日常开发剩余的核心需求集中在两件事快速定位某次改动以及给版本打标记。先把最常用的一组 log 参数串起来看git log --graph --prettyoneline --abbrev-commit这条命令输出一个分支拓扑图每个提交只显示一行哈希取短格式。排查分支合并关系时它比默认 log 直观得多。如果最近一次提交改动了哪些文件、每处改了什么用下面这条git log -p -n-n是查最近 n 条提交-p显示每个提交的具体补丁内容。此时输出的信息量较大但正好可以当作 code review 的本地自查工具。配合git log --stat -n只看改动文件统计能快速判断某次提交涉及的范围是否合理。diff 系列在版本定位中同样高频三个常用维度git diff HEAD git diff --stat git diff 分支名git diff HEAD用于对比当前工作区与最近提交之间的所有差异未暂存和已暂存的改动都能看到git diff --stat只输出文件清单和增删行数适合快速扫一眼改动面大小git diff 分支名对比当前分支与目标分支的最新差异。注意最后一条的比较基准是两分支各自的 HEAD不是工作区状态。跨历史版本对比用git diff 哈希1 哈希2配合 log 里拿到的提交哈希使用。代码发版时的操作链条一般是这样git tag -a v1.1 -m Version 1.1 git push origin v1.1tag -a创建带注释的标签-m写标签说明。轻量标签直接写git tag v1.1只记录指向的提交没有额外信息。查看全部标签用git tag查看某个标签指向的提交和注释内容用git show 标签名。资源文档里提到可以用git tag 标签名 分支名给指定分支的末梢打标签也可以直接对准某个提交号。发布流程中还需要注意标签推送的位置。git push origin 标签名推送单个标签git push origin --tags会把所有未推送的本地标签一次性推上去。删除本地标签用git tag -d 标签名删除远程标签用git push origin --delete tag 标签名。这里有一个容易踩坑的点标签删除后指向的提交仍然存在只是失去了标识。发版前最后检查一遍提交状态我通常会按这个顺序执行git status git log --oneline -5 git diff --stat先看工作区有没有遗漏的未提交文件再确认接下来要发布的提交序列是否符合预期最后看改动范围是否包含预期文件。这套检查流程在多人分支上尤其有效能提前发现误提交的内容。资源文档中没有单独提炼过这套组合但它的作用就是把状态查看、历史定位和差异确认串成一次标准体检。标签在推送前先本地创建并git show确认指向无误再执行 push避免把错误标签发布出去。从那以后我每次准备提交或推送时都强制自己先看一眼 status 和 log在动 reset 或 rebase 之前必然留一条 reflog 记录。这份备忘的价值不在于每条命令多复杂而在于它把“该在什么时候用哪个操作”整理得足够清楚遇到拿不准的边界参数先回来翻一遍再动手。希望帮到你。本文还有配套的精品资源点击获取