Git 这工具凡是写过代码的基本都绕不开。但说实话我见过太多人用了几年 Git翻来覆去就那么几个命令clone、add、commit、push、pull。真遇到需要改提交信息、撤销误操作、分支合并出冲突的时候要么上网现搜要么满头大汗地折腾半天。这篇东西我就按我自己平时干活的路子把Git 基本指令里真正高频、真正能救场的常用指令从头到尾捋一遍。不讲虚的全是实际敲过的命令和踩过的坑新手照着抄就行老手可以跳着看重点看看后面 commit amend 和远程密钥配置那几节。之所以想写这个主题是因为最近带几个刚入职的同事熟悉项目发现很多人不是不努力是压根不知道 Git 还有后悔药和时光机这回事。git commit --amend用了不到十次分支回退只知道git reset --hard远程仓库每次都要输密码这些问题每一个都值得单独掰开揉碎讲清楚。这篇内容覆盖了几个层面Git 的安装和初始配置、日常文件操作的完整流程、提交历史的修改与补救、分支管理、远程仓库协作以及一批高频报错的应对方法。适合刚接触 Git 的新手从头看也适合已经用了一段但心中有疑惑的开发者查漏补缺。1. 环境准备安装 Git 与初始化配置1.1 不同操作系统下的 Git 安装方式先把工具装上。Windows 用户最常见的是去官网下载安装包一路 Next 就行。不过我更推荐用包管理器来装省得以后升级麻烦。Windows 上如果你装了 Chocolatey一行命令就能搞定choco install git -ymacOS 用户就简单多了brew install git搞定。Linux 的话Debian/Ubuntu 系用apt install gitCentOS/RHEL 系用yum install git。装完验证一下git --version能输出版本号说明安装成功。这里有一个小建议如果输出的是类似git version 2.x.x的提示确认版本不低于 2.23。因为 2.23 引入了git switch和git restore这组更安全的分支切换/文件还原命令比老的git checkout语义清晰太多新手学习成本直接减半。安装本身没什么难度真正容易忽略的是安装完成后的配置。很多人装完 Git 就直接 clone 代码开始干活结果第一次 commit 就报错说缺少 user.name 和 user.email。别慌这个不是故障是 Git 在很负责地提醒你它需要在提交记录里留下谁做的。1.2 全局身份配置和换行符处理配置身份信息用下面两个命令git config --global user.name 你的名字 git config --global user.email 你的邮箱这个配置是全局的意思是这台机器上所有仓库都会用这个身份。但如果公司项目要求提交身份用公司邮箱而你个人项目想用私人邮箱那就别加--global进仓库目录后去掉这个参数重新设一遍就行。仓库级别的优先级高于全局这样同一个电脑上不同项目能有不同的身份。还有个建议配置和跨平台协作有关。Windows 和 Linux/macOS 的换行符不一样如果处理不好你会看到 git diff 里整个文件都是红的——没改代码就是因为每行结尾的换行符被改了。建议 Windows 用户执行这一条git config --global core.autocrlf true这个配置的意思是checkout 代码时Git 自动把 LF 换成 CRLFcommit 时又把 CRLF 换回 LF。这样仓库里存的始终是统一格式团队成员之间不会因为换行符互相制造噪音。macOS 和 Linux 用户一般不用设保持默认就行。注意这几个全局配置只要执行一次就好了。配置保存的位置在用户主目录下的.gitconfig文件里你完全可以手动打开看看里面写了什么理解 Git 配置背后的逻辑。2. 日常工作流从工作区到远程仓库的完整链路2.1 文件状态与提交的底层概念大部分人对 Git 的理解停留在保存代码这个层面但这种理解会导致后面学分支、学回退时脑袋转不过弯。Git 里的文件有四种状态理解它你就理解了一半的 GitUntracked未追踪、Modified已修改未暂存、Staged已暂存、Committed已提交。拿一个生活场景类比。你的工作区就是你的办公桌桌子上有各种文件。git add相当于你拿了一个文件夹把这些文件整理放进去准备交上去。git commit相当于真的把这个文件夹交到档案室录入了编号随时能调出来。最关键的认知是提交不是存个盘那么简单它是建立一个可回溯的存档点你可以随时回到任何一个存档点。那日常工作流到底怎么走我建议你养成这样一个肌肉记忆git status # 先看当前状态 git diff # 再看具体改了哪些内容 git add file # 把需要提交的文件加进来 git commit -m 描述这次改动 git push # 推到远程仓库每次提交前先git status和git diff这两步能帮你挡掉 90% 的失误。我见过有人图省事上来就git add .把配置文件、临时文件一起提交了后续排查问题的时候别提多痛苦。2.2 高频指令详解add、commit、status、diff逐条说下最核心的指令。git status可能是最安全的命令随意执行不会改变任何东西。它的输出分为几个部分当前分支、与远程分支的领先/落后情况、工作区文件变化。新手看这个命令的输出时注意区分Changes not staged for commit和Changes to be committed两块前者代表还没git add后者代表已经暂存了。git add有几个常用变体git add .把当前目录所有改动都加进来包括新文件和修改的文件git add -u只跟踪已追踪文件的修改和删除不添加新文件git add -p交互式地逐个区块让你决定是否暂存我强烈建议所有人都学一下这个它让你告别一把梭式的提交可以自由地把同一份代码的多个逻辑改动拆成多个提交这在 code review 时是加分项。git commit是建立存档点的指令。提交信息不是随便写的推荐用动词开头概括改动意图。比如fix: correct typo in login validation明显好过update login。很多团队对提交信息有规范要求即便个人项目好的提交信息也是未来的你在向你求助时的救命文档。git diff是看改动详情的工具它显示的是工作区和暂存区之间的差异。如果你想看暂存区和上次提交之间的差异得用git diff --cached。想看统计信息改了哪些文件每个文件加了几行删了几行可以加参数git diff --stat这个参数在 code review 和提交前自查时极其好用。2.3 提交历史的查看与分析git log用于查看提交历史。新手不用记太多花哨的参数先掌握几个就够用了git log --oneline -5 # 只看最近5条每条一行简洁显示 git log --graph --all # 图形化显示全部分支关系 git log -p -- file # 查看特定文件的完整修改历史第三条非常有含金量。当你接手别人代码想搞明白一个文件为什么会变成现在这样git log -p -- 文件名会把该文件每次提交的完整 diff 全部列出来等于给你放了一部这个文件的演变纪录片。配合git blame使用效果更佳。想定位某一行代码是谁写的、哪次提交写的、为什么这么写运行git blame src/main.py注意心态用 blame 的目的不是甩锅而是找到原作者问一句当初这么写是考虑了什么问题。代码里的历史信息价值极高比大部分注释都可靠。3. 提交的补救与修改amend、reset、revert3.1 用 git commit --amend 修改最近一次提交很多人在提交完之后发现打错字了、漏了文件、或者提交信息写错了第一反应是再提交一次把上一次覆盖了。这种思路本身没错但会导致提交历史里多一条无意义的记录。正确做法是用git commit --amend。这个命令能不能用好直接反映出你对 Git 的理解深度。git commit --amend做的事情是把当前暂存区的内容合并到最近一次提交里并替换掉原来那条提交。举例你 commit 后发现自己漏了一个文件正确的流程是git add 忘记的文件 git commit --amend --no-edit--no-edit表示保留原来的提交信息不加这个参数的话会变成编辑器你可以顺带修改提交信息git commit --amend -m 修正后的提交信息用这个命令特别要注意一个问题amend 会改写 Git 历史因为原来的提交被替换成了一个新的提交对象。这在本地操作毫无问题但如果你已经把这次提交推送到远程然后又在本地 amend就出现本地和远程历史不一致的情况。此时再 push 会被拒绝你需要用git push --force强制推送。在有其他人的协作分支上强制推送是危险操作可能覆盖掉别人的提交。所以一条铁律只 amend 那些尚未推送的提交或者只在你自己专用的个人分支上使用。3.2 撤销改动reset 和 revert 的选择Git 提供了两个重要的撤销工具很多新手分不清场景用错后追悔莫及。git reset是把 HEAD 指针往后挪可以带着参数控制是否丢弃工作区改动git reset --soft HEAD~1 # 撤销上次提交但保留所有改动在暂存区 git reset --mixed HEAD~1 # 默认行为。撤销提交和暂存但保留工作区文件内容 git reset --hard HEAD~1 # 彻底丢弃上次提交和所有改动空间上不可逆--soft适合你刚 commit 完发现忘提了几个文件想重新整理一次性提交--hard是你确认之前的改动全都不要了比如试验性代码。但--hard是非常危险的指令属于没有后悔药的后悔药。如果你使用--hard后发现其实还需要某些内容唯一希望是 reflog这个我在后面排查章节会补充。git revert则走的是另一条路它不是移动指针而是创建一条新的提交用反向 diff 去抵消目标提交的内容。这意味着历史被保留了下来原提交还在但项目代码回到了之前的状态。这个操作在共享分支上是安全的因为你不改历史只是追加记录。选哪个给你一个决策标准如果分支是你一个人在用还没推送给别人reset随心所欲如果分支已经推送过或者别人拉了你的分支那就用revert。宁可多几条改动被抵消的记录也不要让别人仓库里的历史和你自己的历史对不上。这个经验我付出了不小的代价才总结出来——有一次在团队分支上用了reset --hard再强推直接把同事的提交冲掉那个场景我一辈子都忘不了。3.3 从暂存区移除和从工作区还原还有两个进阶操作日常救急场景经常用到。把文件从暂存区退出来但保留工作区的内容git restore --staged file旧版本的习惯写法是git reset HEAD file现在用restore语义更明确老命令也没过期看团队习惯。注意这个操作只影响暂存状态文件内容一个字节都不会变。把工作区的文件恢复到和暂存区一致也就是丢弃工作区对于这个文件的改动git restore file这条命令会直接覆盖你的本地文件改动无法找回执行前务必确认。至于要放弃一大片改动重新来git stash是更好的方式git stash # 保存当前工作区所有未提交改动回到干净状态 git stash pop # 恢复最近一次暂存的改动 git stash list # 查看所有暂存的改动列表Stash 的典型场景是你正在一个分支开发功能突然线上出了紧急 bug 需要切到别的分支修但你不想提交半成品代码。Stash 一把代码收起来切分支修 bug修完切回来stash pop继续干活。这功能在救急场景里非常顺手。需要留意的是 stash 默认只暂存已追踪文件的改动新建的未追踪文件不包含进去想一并暂存得加-u参数。4. 分支与合并日常协作的核心操作4.1 分支的创建、切换与删除分支是 Git 最强大的特性也是理解门槛最高的概念。有人说分支是平行宇宙每个分支上你可以自由折腾不影响主线折腾出成果了再把分支合并回去。现代 Git 推荐用switch而不是checkout来切换分支理由我在前面说过语义更清晰。常用命令如下git branch # 列出本地分支当前分支前有 * 号 git switch -c feature/login # 创建并切换到一个新分支 git switch main # 切换到已有分支 git branch -d feature/login # 删除分支-d 检查是否合并-D 强制删除创建分支的最佳时机是每次开始一个新功能或者修一个 bug 前给想象中这个功能单开一条线它有独立的生命周期失败了整体删除不心疼成功了再合并回主干。这个习惯让主干始终保持可发布状态这个价值在多人合作中被放得无限大。合并分支主要是git merge。它把另一个分支的提交历史并入当前分支。简单的合并快进合并不会产生新的提交节点直接把指针往前移但发生分叉后Git 会创建一个新的合并提交把双方的改动归纳起来。4.2 冲突的起因、处理和预防合并过程中最常见的噩梦是冲突conflict。冲突的本质是两个分支修改了同一处代码Git 不知道该听谁的只能把问题抛给人类。打开冲突文件你会看到类似这样的标记 HEAD 当前分支的内容 另一个分支的改动 feature/login冲突解决流程是打开文件、逐段选择保留哪边或者两边都要、删掉、、三个标记、然后git add标记为已解决最后git commit完成合并。这个过程不要慌冲突是任何真实项目的常态不是异常。预防冲突的实操建议有三条第一保持分支生命周期短暂功能开发和主干同步的频率越高冲突面越小第二做大规模重构前先和其他人的改动沟通对齐第三合并前先在目标分支上git pull拉最新代码再切回工作分支执行合并能降低不小冲突概率。画像再具体一点一个人改了一个接口的签名另一个人在另一个分支用了这个接口合并时必然冲突。这类结构性冲突没有银弹只有靠团队内部良好的沟通习惯来弱化。4.3 rebase 的使用时机与风险git rebase也是整合分支的另一个选择。它和 merge 的哲学不同merge 是记录真实发生的事情rebase 是让历史变成一条干净的直线。git rebase会把当前分支上的提交摘下来在目标分支的最新提交上逐个重新铺设最终呈现一条线性历史。很多人喜欢这效果因为它让 log 非常干净查起来一路顺畅。风险在于rebase 同样改写提交历史。如果那个分支已经推到远程、其他同事也在用你 rebase 之后强推会造成对方的本地历史和远程脱节随之而来的就是一大堆混乱。我的个人建议是在公共分支上坚决不用 rebase自己开发的功能分支可以随意。你如果还分不清什么时候该用哪个那就先无脑用 merge安全第一。5. 远程仓库克隆、推送、拉取和 Gitee 密钥配置5.1 远程仓库的核心指令与协同流程远程仓库是分布式协作的中转站。本地的提交只是你一个人机器上的记录git push把提交推到远程git pull拉取其他人的提交。多人的协作流程本质上就是不断 push 和 pull 的过程。常用指令git clone url 项目名 # 首次获取代码 git remote -v # 查看远程关联了哪些地址 git push origin main # 推送本地分支到远程对应分支 git pull origin main # 拉取远程分支的最新改动 git fetch origin # 只下载远程最新变动不合并重点讲下git pull的本质它其实是git fetch加上git merge的复合命令。先把你没有的提交拿到本地暂存区再把它们和你当前所在分支合并起来。如果你想用 rebase 替代那步 merge就执行git pull --rebase养成这个习惯在多人协作时能有效减少无意义的合并提交记录让历史更干净。推送前先看下自己领先多少git status输出里会明确提示Your branch is ahead of origin/main by 3 commits这时候 push 就万无一失。如果提示领先又落后说明远程有你没有的提交强行 push 会被拒绝Git 会建议你先 pull 再 push。照做就行这就是保护机制在起作用。5.2 SSH 协议替代 HTTPSGitee/GitHub 密钥配置完整记录每次 push 都要输入用户名密码这件事实在影响效率。更别提密码里带特殊字符时一旦输入错误还得重新来一遍。解决办法是配置 SSH 免密登录。我用 Gitee 为例走一遍完整的流程。首先检查你电脑上有没有现成的 SSH 密钥这一步很关键别一把钥匙开多把锁容易混乱ls -al ~/.ssh看到id_rsa和id_rsa.pub文件说明之前生成过可以复用直接跳到第三步。没有的话生成一个新的ssh-keygen -t rsa -b 4096 -C 你的邮箱中间会提示你选择保存路径和设置密码全部直接回车是最省事的方案。执行完会在~/.ssh目录下生成一对文件私钥id_rsa自己留着绝不能外泄和公钥id_rsa.pub可以也必须要放到服务器上。然后查看公钥内容cat ~/.ssh/id_rsa.pub复制整段以ssh-rsa开头的内容。接下来访问 Gitee 网站进入设置 → SSH 公钥粘贴进去并输入一个名字保存。这样你本地就有了访问远程仓库的凭证。最后验证配置是否成功ssh -T gitgitee.com看到欢迎语说明配置成功。把仓库地址从 HTTPS 改成 SSH 格式的方式git remote set-url origin gitgitee.com:用户名/仓库名.git这之后再 push 就不用输密码了体验顺畅不少。5.3 .gitignore 的编写和常见陷阱.gitignore是远程仓库的门卫。它决定了哪些文件不能被 Git 追踪。版本仓库里不该放进去的典型成员包括本地环境配置、IDE 专属文件、构建产物、依赖目录等。特别是node_modules/这类的目录动辄几万个小文件一旦被提交进去后续每次 pull/push 都会背负沉重的性能负担而且毫无意义。一个常规的 Python 项目最小化的.gitignore示例__pycache__/ *.pyc .env .venv/ dist/ *.log写.gitignore时有一个高频陷阱如果你在添加 ignore 规则之前某个文件已经被 Git 追踪了那规则不会自动生效——已追踪文件不会因为被 ignore 就停止追踪。需要用下面的命令将它从索引移除保留工作区文件git rm --cached 文件名执行后再 commit这个文件才真正退隐。这个坑会让不少人以为是.gitignore写错了。6. 常见问题与排查技巧实录6.1 高频报错速查表把平时团队里新人问得最多的一批报错整理成一张表直接对着找自己的问题。报错信息产生原因解决办法Please tell me who you are没设置 user.name 和 user.email执行全局配置命令failed to push some refs远程有本地没有的提交先 pull 再 pushfatal: Not a git repository当前目录不是仓库或仓库损坏检查路径在仓库根目录执行Permission denied (publickey)SSH 密钥未配置或不对检查~/.ssh用ssh -T验证You have unmerged paths有未解决的冲突打开文件解决冲突add 后 commitLF will be replaced by CRLF换行符跨平台差异配置core.autocrlf第一条的解决方案前面已经讲过这里重点说一下Permission denied。如果确认公钥已经加到 Gitee 上依然报错建议执行下面命令开启 SSH 调试信息ssh -vT gitgitee.com它会打印整个连接过程。大多数人最终发现是用了错误的用户邮箱或密钥路径不对debug 输出里基本都能定位。6.2 误操作恢复reflog 的用法与边界Git 最令人安心的地方是你很难彻底删除东西前提是你要知道门道。git reflog会记录你本地所有 HEAD 移动的历史它就是你操作 Git 的日志黑匣子。即使是你不小心reset --hard只要那条提交还在 reflog 里就能找回来。具体操作git reflog输出会按时间倒序列出最近一段时间的所有 HEAD 指向变更包括 reset、merge、checkout 和 rebase。每条记录前面有一串哈希值是你当时所在提交。例如你误执行了git reset --hard HEAD~3在 reflog 里找到被丢弃前的那条记录恢复方式git reset --hard 目标提交哈希一个真实的场景是有次我误删了一个分支当时差点崩溃。后来发现分支删了但提交还在用 reflog 找到那个分支指向的提交git branch 恢复名 哈希直接重建问题解决。如果说 commit 是存档点reflog 就是存档点的备份记录。所以我的铁律是当你怀疑自己丢失了工作之前先别急着重装系统或者清理磁盘看一眼 reflog大概率还在。6.3 关于协作规范的几条建议最后补充几条关于团队协作的实战经验它们不算严格意义上的命令但比命令还重要。第一分支命名尽量带上需求或 bug 编号feature/123-login-page。这个习惯让你在几个月后面对几十个本地分支时依然能一眼认出哪个是哪个。第二提交信息首行控制在 50 个字符左右。这不是强迫症而是因为很多 Git 工具在列表视图里只显示首行写多了会被截断反而看不清楚。第三推送前在两分钟内用git diff 目标分支名检查一下自己相对那分支改了哪些东西把临时调试代码剔除干净再问自己一句这个代码我明天看还能不能看懂能再推送。第四不要养成git add .的习惯。每次提交明确指定提交文件保持提交粒度和逻辑一致冲突解决、回滚排查、code review 的体验都会显著升级。团队里最让人头疼的不是代码混乱而是提交里面混着一堆无关文件跟拆盲盒似的。收尾的实话我自己刚开始用 Git 的时候也觉得命令记不清很正常反正到处能搜。但在一次线上事故回滚中因为不熟悉 reset 和 revert 的区别浪费时间后我下定决心把所有高频指令练成肌肉记忆。现在带新人时我最常说的一句话是Git 不复杂它只是把复杂的选择权交给了你。你越熟悉这些指令的语义和边界就越能从容地试错因为你知道一切损失都是可恢复的。日常工作中我仍然偶尔会查文档这不是什么丢人的事关键在于遇到问题别慌先用 status 和 reflog 稳住局面再往下走。希望这篇文章能把你在 Git 路上的启动阻力降到最低真正做到常用指令用得出、冷门指令能找到。