Git指令详解：从基础操作到rebase、stash等进阶实战

git 指令这个东西说实话很多人用了两三年翻来覆去还是那几条clone、add、commit、push、pull。不是说不行而是真遇到了提交信息写错、分支乱成一团、误删代码找不到的情况才意识到自己对 git 的理解还停留在“工具人”阶段。我最初接触 git 的时候也差不多直到有一次推错分支把测试代码怼到生产仓库被同事连环 call 之后才开始老老实实把指令体系捋了一遍。这篇就把我实际工作中反复用到的 git 相关指令做个梳理从安装配置到日常操作再到 amend、rebase、stash 这些进阶玩法顺带把踩过的坑一并写上给正在啃 git 命令的朋友做个参考。你不需要背下所有指令只需要理解 git 的底层逻辑配合几条高频命令就可以应付绝大多数场景。我下面写的都是自己电脑上验证过、团队协作中真实用过的命令不是从文档里摘出来凑数的。1. 环境准备安装 Git 与初始化配置1.1 安装 Git三个平台的选型与注意事项Git 的安装本身不难但不同平台的坑不一样。Windows 上推荐直接去 Git 官网下载安装包也可以在软件管家或国内镜像站下载。官网下载慢的时候用国内镜像的速度会快很多。安装过程不需要全点下一步有几个选项要注意一下选择编辑器默认是 Vim如果你平时不用 Vim建议选 Visual Studio Code 或 Notepad否则后面 commit 填信息的时候弹出来的 Vim 界面会让你怀疑人生。PATH 环境变量选 “Git from the command line and also from 3rd-party software”。这条很关键选错的话在 Windows Terminal 或 CMD 里敲 git 会提示找不到命令。行尾转换Windows 上建议选 “Checkout Windows-style, commit Unix-style line endings”。这样避免因为 CRLF 和 LF 差异导致整个文件都被标记为改动这个坑我在团队项目里反复踩后面会说。macOS 上一般自带 git不过版本可能比较老。用 Homebrew 装一下更省心指令是brew install git。Linux 上根据发行版选择包管理器Debian/Ubuntu 用apt install gitCentOS/RHEL 用yum install git。安装完之后先别急着建仓库打开终端敲git --version看到版本号输出就说明环境没问题。Windows 上如果用的是 Git Bash它自带一套 Unix 风格的命令环境ls、pwd、rm 都能直接用这也是很多人喜欢它的原因——在 Windows 上能体验 Linux 终端的操作感同时跑 git 指令完全无压力。1.2 初始化配置用户名、邮箱与换行符装好之后第一件事就是配置身份信息。这一步很多人跳过等第一次 commit 的时候就傻眼了提交者显示成一堆乱码或者邮箱为空。配置指令很简单git config --global user.name 你的名字 git config --global user.email 你的邮箱--global 表示全局生效也就是这台机器上的所有仓库都用这个身份。如果你在某个项目里需要不同的身份可以在那个仓库目录下不加 --global 重新配置一次它会覆盖全局设置。除了身份信息还有几个配置是我每次装完 Git 必改的。首先是默认编辑器如果你之前选错了现在可以用指令补救git config --global core.editor code --wait这样提交的时候会自动打开 VS Code保存关闭后自动完成 commit比在终端里排版舒服太多。还有换行符的策略用git config --global core.autocrlf true开启自动转换Windows 下基本不会因为换行符扯皮。最后别忘了确认配置有没有生效git config --list输出里能看到 user.name、user.email 就说明配置没问题。这些基础配置看起来不起眼但它们直接影响提交记录的规范性和团队协作的效率。1.3 SSH 密钥配置打通 Git 平台认证日常推送代码到 GitHub 或 Gitee 有两种认证方式HTTPS 和 SSH。HTTPS 每次 push 都要输账号密码虽然可以配置 credential helper 缓存但 SSH 一次性配置好之后后续推送不用再输任何密码体验好太多。生成 SSH 密钥的指令ssh-keygen -t rsa -b 4096 -C 你的邮箱一路回车就行默认生成在~/.ssh/id_rsa。生成的公钥在~/.ssh/id_rsa.pub里用cat查看然后复制整段内容粘贴到 GitHub 的 Settings - SSH Keys或者 Gitee 的 SSH 公钥设置里。添加完后测试一下ssh -T gitgitee.com看到 “successfully authenticated” 之类的提示就说明认证通了。这个步骤我第一次配置的时候卡了很久原因是用管理员身份运行 Git Bash 导致 ssh-agent 没加载到正确的密钥后来切回普通用户就好了。如果测试时提示权限问题可以先执行ssh-add ~/.ssh/id_rsa再重新测试。密钥配置好之后克隆仓库的地址要选 SSH 格式也就是gitgithub.com:用户名/仓库名.git不要再用 HTTPS 的地址。很多人配置完密钥还是用 HTTPS 地址克隆结果还是每次输入密码这不是配置失败是地址选错了。2. 日常操作指令详解从工作区到远程仓库2.1 提交管理git add 与 git commit 的细节日常开发中改动代码后第一件事就是git add把文件从工作区加入暂存区。我见过很多人习惯用git add .一把梭图省事但这样做有隐患——会把不该提交的文件、临时调试代码一并加进去。我的习惯是用git add 具体文件路径或者先用git status看清楚改动列表再决定。需要用到的高频指令git status # 查看工作区状态哪些文件改了、哪些已暂存 git add index.html # 添加指定文件到暂存区 git add src/ # 添加整个目录 git add . # 添加所有改动慎用 git rm --cached a.txt # 将 a.txt 从暂存区移除但保留本地文件git status会告诉你一个关键信息暂存区和工作区之间的差异。如果看到 “Changes to be committed” 说明文件已经 add 了如果看到 “Changes not staged for commit” 说明文件改了但还没 add。每次 commit 之前我都会扫一眼这个输出防止漏提或者多提。commit 指令更讲究。git commit -m 提交说明是最常见的形式但提交信息怎么写很多人完全不思考。我看到过 git log 里出现 “更新”“修改”“111” 这种说明等三个月后想排查一个问题看到这种日志简直想砸电脑。规范的提交信息应该说明“为什么改”而不是“改了什么”。比如fix: 修复订单超时状态未更新的问题比更新订单模块要好得多。还有一个细节git commit不带-m时会打开编辑器让你写多行提交说明第一行是概要空一行后写正文。这适合提交内容比较复杂的场景多写几句话不会后悔。2.2 查看历史与差异git log 与 git diff 的实用姿势提交完代码怎么回头查看历史记录git log是基础但默认输出太啰嗦我看得最多的是这几条git log --oneline # 简洁模式每条提交一行显示短哈希和提交说明 git log --oneline --graph # 带分支图的简洁日志分支分叉和合并一目了然 git log -5 # 只看最近 5 条 git log --author名字 # 按作者筛选 git log --since2 weeks ago # 按时间筛选--graph参数我尤其推荐它能用字符画出分支的合并曲线。团队协作时谁在哪个时间点合了哪个分支线图上一眼就能看出来比翻聊天记录靠谱多了。改动差异的查看核心指令是git diff。它有三个场景需要区分git diff # 工作区和暂存区之间的差异 git diff --cached # 暂存区和最近一次提交之间的差异 git diff HEAD # 工作区与最近一次提交之间的差异理解这三个场景其实不难工作区就是你当前文件的状态暂存区是你 add 过的最新状态HEAD 是上一次 commit 的状态。git diff加上--stat参数可以只看文件级别统计哪些文件改了几行一目了然。改动比较多的时候先用--stat宏观了解再进具体文件看细节。2.3 分支与合并git branch 与 git merge 的核心机制分支是 git 最强大的设计之一也是新手最容易绕晕的部分。你把分支想象成平行宇宙不同支线上的修改互不打扰最后通过合并把成果汇总。实际用到的指令不多git branch # 查看本地分支当前分支前有星号 git branch feature/login # 新建分支 feature/login git checkout feature/login # 切换到该分支 git checkout -b feature/login # 新建并切换等价于上面两条指令合并 git merge feature/login # 把 feature/login 合并到当前分支这里解释一下 merge 的原理它会把目标分支和当前分支的共同祖先开始直到两个分支最新提交为止的所有更改尝试合并成一个新的提交。如果两边改的是不同文件merge 通常很顺利如果改的是同一个文件的同一个区域git 会标记为冲突需要手动解决。我在实际项目里如果 feature 分支开发周期比较长我会定期把主分支 merge 到 feature 分支里让功能分支保持相对最新。这样最后合并回主分支时冲突会少很多而且即使有冲突也是在功能分支上解决改坏了顶多重新开分支不会污染主线。2.4 远程仓库同步git remote、push、pull 与 fetch代码最终要推到远程仓库团队协作才能进行。远程同步相关指令git remote -v # 查看远程仓库地址 git remote add origin 仓库地址 # 首次关联远程仓库 git push origin main # 推送当前分支到远程 main 分支 git push --set-upstream origin main # 首次推送时建立本地分支与远程分支的关联 git pull # 拉取远程更新并自动合并 git fetch origin # 拉取远程更新但不合并先看再决定很多人分不清 pull 和 fetch 的区别。fetch 是把远程仓库的提交记录拉下来但不会动你当前的工作区pull 则在 fetch 之后自动执行 merge也就是说你的本地代码会被改变。所以我遇到不确定远程更新会不会产生冲突的情况会先用 fetch再git diff 本地分支 origin/远程分支看一下差异最后决定要不要 merge 或直接 pull这样主动权在自己手里。首次推送新分支时加--set-upstream这个参数是个好习惯它把本地分支和远程分支的追踪关系记录下来以后在这个分支上直接敲git push或git pull就能自动匹配远程分支不用每次带全参数。3. 进阶指令与实战技巧解决“后悔”和“整理历史”的刚需3.1 git commit --amend修改提交信息还能这样用git commit --amend是热搜词里出现频率很高的指令它的用途是修正上一次提交。最常见的场景提交完之后发现自己 commit message 写错字了或者忘记把某个文件加进去了这时候如果硬着头皮再提一次git log 里就多了一条“补充提交”的垃圾记录看着很不专业。正确的做法是先把遗漏的文件git add到暂存区再执行git commit --amend -m 修正后的提交说明这条指令会把上一次的提交替换掉——注意是替换不是新增。所以执行完之后git log里仍然只有一条提交记录但它的哈希值变了提交说明和包含的文件都是新状态。这里必须提醒一个重大注意事项amend 只适用于还没有 push 到远程仓库的提交。如果已经 push 了其他人很可能已经基于这个旧的提交做了操作你再 amend 会改变提交历史导致别人 pull 时出现分叉。团队协作中遇到“已推送的提交信息写错了”正确做法是不要 amend直接新提一个chore: 修正上一次提交的说明虽然丑一点但没有风险。我自己的经验是push 之前先看一眼自己的 commit 信息能不发 amend 就不发。3.2 git rebase把混乱的提交记录整理成线性rebase 和 merge 一样都是用来整合分支的。但它们的理念完全不同merge 保留所有分支的真实分叉结构好处是保留了完整历史rebase 是把一个分支的提交“平移到”另一个分支的最新提交之上这样历史记录变成一条直线阅读起来非常清爽。基本用法git checkout feature/login git rebase main这段指令的含义是把 feature/login 分支上从与 main 分叉点开始的提交逐一重新应用到 main 的最新提交之上。执行过程中如果遇到冲突git 会停下来让你解决解决后执行git add 文件然后git rebase --continue直到所有提交都重放完毕。为什么我要说它“整齐”而不是“更好”因为 rebase 实际上重写了提交历史它把每个提交的父提交都改了所以提交哈希值全变了。这带来一个限制千万不要对已经推送到远程共享分支的提交做 rebase否则会害惨所有协作者。我自己对 rebase 的态度是本地分支、还没 push 的提交放心用 rebase。已 push 的远程分支绝不用 rebase 去动历史。想把远端分支拉到自己分支尾部优先用 rebase想把分支合回主分支用 merge 更安全。我还常用git rebase -i main做交互式整理它可以对分支上的多个提交进行合并(squash)、修改(reword)、删除(drop)。比如你开发一个功能提交了七八次全是“改一个字符”“调下格式”这种碎提交集合成 rebase -i 界面后可以把它们 squash 成一个完整的功能提交推上去之后这个功能的提交历史会干净很多。3.3 git stash临时切换分支也能保住手头改动开发中经常遇到这样一个场景你正在 feature-A 分支上写代码写到一半突然说线上来了 bug 要立刻去修但手上的改动还没完成不能提交。如果直接切分支git 是拒绝的因为工作区的未提交改动会被带过去或冲突。git stash就是为此设计的它能把工作区和暂存区的改动临时保存到一个栈里把工作区清空成干净状态。切到 hotfix 分支修完 bug 再切回来用 stash 恢复现场。git stash # 暂存当前改动 git stash list # 查看暂存记录列表 git stash pop # 恢复最近一次暂存并删除该记录 git stash apply # 恢复最近一次暂存但不删除记录一般用不到 git stash drop stash{0} # 删除指定暂存记录慎用我习惯在 stash 时加一条描述方便恢复时辨认git stash save 登录功能开发中表单校验还没做git stash有一个坑默认不会暂存新建的未跟踪文件。如果新建的文件还没 add 过stash 之后它们还留在工作区。要连新文件一起暂存用git stash -u。这个参数我第一次没记住导致切分支后新文件留在了原来的工作区切回来差点以为文件丢了。3.4 git reset 与 git reflog给误操作留一条后路git 最让人安心的特质是大部分操作都能反悔。git reset是回滚提交的主力但它有几种模式很多人分不清楚git reset --soft HEAD~1 # 撤销最近一次提交但保留所有改动在暂存区 git reset --mixed HEAD~1 # 撤销最近一次提交改动保留在工作区默认模式 git reset --hard HEAD~1 # 撤销最近一次提交改动直接丢弃慎用--soft和--mixed的区别在于改动停留在暂存区还是退回工作区。--hard则非常危险它会把代码恢复到指定提交的状态你当前所有未提交的改动都会被丢弃。我使用--hard前一定先确认当前分支的改动是不是真的不要了。如果--hard之后发现自己误删了改动还有最后一招git reflog。它记录了所有的 HEAD 变动包括 reset、rebase、checkout 等操作的之前状态git reflog输出里每一行都是一个操作的记录包含操作类型、HEAD 位置哈希和操作说明。如果你拿到了误操作之前的哈希值就可以用git reset --hard 哈希值回到那个状态。这个指令是我给所有新同事推荐的保命技能它把 git 的“后悔”边界扩大到了几乎所有误操作。4. 常见问题与排查技巧实录4.1 推送被拒绝怎么处理看到 “! [rejected] main - main (fetch first)” 这种提示通常意味着远程仓库有你本地没有的提交你的推送没有基于最新的远程状态git 出于安全拒绝覆盖。解决办法很简单先 pull 或 fetch merge再 push。我建议按这个顺序来git fetch origin git diff HEAD origin/main # 先看差异 git merge origin/main # 合并远程改动 # 解决冲突后 git push如果远程分支的历史和本地差异比较大merge 可能会产生一条合并提交记录。不想看到这个合并提交的话可以先 pull 用 rebase 模式git pull --rebase origin main它会把本地未推送的提交放到远程最新提交的上面保持历史线性。之后 push 就不会被拒。这个方法我在多人频繁 push 同一个分支的场景中几乎天天用尤其在代码 review 期间其他人可能刚合了你的同事的 MR你不 rebase 一下基本推不上去。4.2 合并冲突的解决流程无论 merge 还是 rebase只要两个分支修改了同一个文件的同一块区域就会出现 “CONFLICT (content): Merge conflict in 文件名” 的提示。第一次遇到的用户看到代码文件里满屏的、、会觉得很裂开。其实逻辑很简单。 HEAD到之间是当前分支的改动到 分支名之间是合并进来的分支的改动。你要做的就是手动编辑文件保留想要的代码删掉所有的标记符号然后git add 冲突文件 git commit # 完成合并如果是 rebase 过程中遇到冲突解决后不能用 commit而是git add 冲突文件 git rebase --continue解决冲突时有一个实用原则如果不是你对这块逻辑特别熟尽量不要执着于保留自己的版本而是搞清楚冲突双方的意图。比如对方改了变量名你改了变量类型那就需要用新的变量名配上新的类型而不是二选一。我见过有人在冲突里直接把整段代码删掉重写导致后续编译错误这就是没有认真阅读冲突上下文的结果。4.3 认证失败SSH 权限与密码缓存问题推代码报 “Permission denied (publickey)” 是新手高频问题原因通常是 SSH 密钥没配对或者 ssh-agent 没启动。排查步骤ssh -T gitgitee.com如果提示 “Permission denied”先检查~/.ssh/id_rsa.pub的内容是否已经加到 Gitee 或 GitHub 的设置页。如果公钥没问题再确认本地 ssh-agent 是否加载了密钥eval $(ssh-agent -s) ssh-add ~/.ssh/id_rsa另外一个隐蔽问题同一个电脑配置了多个平台的密钥比如同时用 GitHub 和 Gitee需要通过配置文件指定不同主机用不同密钥。在~/.ssh下新建config文件Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa_gitee配置之后两个平台的 SSH 认证就能正确区分不会出现“GitHub 用着正常Gitee 总提示权限不足”的情况。HTTPS 方式如果总是要求输入密码可以启用凭据缓存git config --global credential.helper store保存一次密码后后续不再询问。但注意明文存密码有安全风险个人电脑用还行共享电脑谨慎使用。4.4 误删分支与误重置代码恢复git branch -D 分支名删错分支是很多人经历过的事故。但 git 有一个隐藏的保底机制分支本质上是一个指向提交的指针只要那个提交还存在分支就能被找回来。恢复指令git reflog --all从输出里找到被删分支最后一次指向的哈希值然后git branch 新分支名 哈希值就能恢复出一个内容完全一样的分支。注意 reflog 记录有时效性一般默认 90 天内可查过期记录会被清理。所以发现自己删错分支了不要慌但也不要拖延尽快用 reflog 找回。如果误执行了git reset --hard导致未提交的改动消失同样先git reflog找到变更前的 HEAD 哈希再用 reset 或 checkout 找回。需要承认的是--hard丢弃的未跟踪文件新文件是无法通过 git 找回的这种文件只能靠编辑器本地历史或其他备份手段恢复。所以我对同事们的口头禅一直是git reset --hard之前先把工作区有问题的新文件复制一份到桌面。5. 我的使用习惯与效率建议5.1 配置别名把高频指令缩到最短git 指令本身不复杂但组合起来有些很长。我在.gitconfig里配了一组别名大幅提升了日常敲命令的速度git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm commit git config --global alias.lg log --oneline --graph --decorate --all配置之后git lg就能看到带分支图的完整提交记录比默认的git log好用太多。还可以配一个提交推送的组合命令git config --global alias.publish push --set-upstream origin新分支首次推送时只要git publish后面不用跟参数自己指定 upstream效率和体验都上一个档次。5.2 提交信息规范与分支命名规范这东西单靠自觉不现实最好形成团队约定。我现在所在团队用的是简化的 Conventional Commits 规范feat: 新功能fix: 修复 Bugdocs: 文档变更refactor: 重构不改变功能的逻辑调整chore: 构建工具、依赖升级等杂项style: 格式调整不涉及逻辑变化分支命名也建议统一比如feature/登录模块、hotfix/修复超时问题、release/1.2.0。这种命名方式的好处是看到分支名就知道它的生命周期和用途issue 系统里也容易对应上。我在团队里还推荐大家用git commit -m feat: ...的格式配合 commitlint 工具做自动化校验。校验不过就不允许提交把提交规范的执行前置到开发阶段就不用等到 code review 时再来回改。5.3 命令行与 GUI 的结合使用很多人纠结到底用命令行还是 GUI 工具。我的答案是两手都要抓。命令行适合执行精确的操作比如 rebase、reset、stash 这种需要明确语义的场景GUI 则适合查看分支结构、代码 diff 对比、暂存区可视化。我自己的使用习惯是日常提交、推送、状态检查用命令行比较轻快。复杂的分支图、超大 diff review 用 VS Code 的 Git 面板或者 IDE 的 git 视图。遇到冲突时先在 GUI 里看冲突两侧的内容再回命令行处理效率更高。命令行和 GUI 之间不是对立关系而是互补关系。我见过只会用 GUI 点按钮的同事遇到 amend 这种操作一脸懵也见过只认命令行的同事在 IDE 里明明有可视化解决的方案还要打开终端敲半天。工具是死的人是活的哪种方式能让你把问题解决干净就用哪种。5.4 再分享一个小技巧批量提交前的变更检查最后分享一个我很早就形成的习惯每次批量提交之前不直接git add .而是执行git status git diff --stat git diff三步走先看状态再看文件级统计最后看具体改动。确认没有临时调试代码、没有误改配置才执行 add 和 commit。有人说这三步太啰嗦但正是这个习惯让我避免过至少三次把本地用户名密码写死在代码里推送到远程仓库的事故。在团队协作中一个人的提交会影响所有人代码进仓库之前多花两分钟检查比之后花两小时回滚要划算得多。