最近在带一个刚入行的同事发现他 Git 用得挺顺add、commit、push 都敲得飞起。但等到代码写岔了要回退、提交信息写错了要改、或者需要把几个乱糟糟的提交整理成一个的时候他就卡住了。鼠标在终端里犹豫半天最后还是打开网盘里存的那份Git 命令大全翻半天也找不到对症的那一条。这其实是挺多人的真实状态基础命令会了但也只是会按回车遇到稍微绕一点的提交整理需求就两眼一黑。图形化工具倒是装了好几个但大多时间也只是用来看看提交记录本质上还是命令行操作。这篇文章我想从实操角度把这些事从头到尾捋一遍。内容覆盖 Git 的安装与初始化、最常用的基础命令、用 amend 修补提交、用 merge 和 rebase 整理分支以及交互式 rebase 的进阶玩法最后再聊几款常见的图形化工具和 IDE 集成。我尽量不用教科书式的讲法而是给你一套我自己日常开发中确实在用的操作逻辑。适合刚接触 Git 的新人也适合工作了一两年但一直没系统整理过 Git 知识的人。1. 先把环境备好Git 安装与初次配置很多人以为装完 Git 就算装好了结果第一次 commit 就报错第一次 push 就认证失败然后跑到群里问为什么。其实这些问题大多不是 Git 本身的问题而是环境初始化和认证配置没做好。1.1 各平台安装 Git 的实操方式Windows 上最省事的做法就是去官网下 Git for Windows 的安装包一路 Next 就能装上。需要注意的一个细节是安装过程中Adjusting your PATH environment这一步建议选Git from the command line and also from 3rd-party software。这个选项会把 Git 的核心命令加进系统 PATH保证你在任何终端窗口里输入 git 都能直接用而不是只能在 Git Bash 里用。另一个常见选项是换行符转换Checkout Windows-style, commit Unix-style line endings 对大多数跨平台项目来说是最不会出事的默认项。macOS 用户我建议直接用 Homebrew 装brew install gitHomebrew 装的版本通常比系统自带的旧版要新不少而且后续升级也省事一条brew upgrade git就搞定。如果你没装 Homebrew去官网下载 macOS 版安装包也可以但版本更新就得手动来稍微麻烦。Linux 用户看发行版Debian/Ubuntu 系列sudo apt update sudo apt install gitCentOS/RHEL 系列sudo yum install git装完后终端里跑一下git --version确认版本。如果看到一个 2.3x 以上的版本号环境就没问题了。这里有个小建议别在过老的 Git 版本上停留2024 年了Git 2.40 以上的版本对 SSH 签名、ref 格式兼容性都友好很多旧版本在处理一些新仓库格式时容易出现莫名其妙的问题。1.2 首次运行前的必备配置Git 装好后的第一件事不是 clone 代码而是告诉 Git 你是谁。这步不做commit 的时候 Git 会报用户名和邮箱缺失或者直接用系统自动推测的错误信息提交上去后面追查历史时很尴尬。git config --global user.name 你的名字 git config --global user.email youremail.com注意这里邮箱最好填你能收到邮件的真实地址很多 Git 平台的提交记录会关联到这个邮箱。以前见过有人随手填了个 testtest.com后来代码出问题想联系作者对着提交记录干瞪眼。除了用户名邮箱我建议顺手把默认编辑器改掉。Git 在某些操作比如 commit 不带 -m、交互式 rebase时会调用默认编辑器让你输入内容默认的 Vim 对很多不熟悉命令行编辑器的同学是一道坎git config --global core.editor code --wait如果你用 VS Code这条命令会把默认编辑器设置为 VS Code输入提交信息时直接用熟悉的编辑器体验顺滑很多。不用 VS Code 的话也可以设置成记事本或者 Sublime Text只要支持等待关闭后再继续这个特性就行。还有一个容易被忽略的配置是pull.rebase。默认情况下git pull走的是 merge 策略会额外产生一个 merge commit。我个人偏向把 pull 设置为 rebase 模式git config --global pull.rebase false这行我没有写死建议值想说明的是这个配置完全看团队协作风格。你在团队里如果习惯了git pull后干干净净地继续开发可以设成true如果你喜欢保留合并痕迹就保持默认的false。核心是要知道有这么个开关而不是等 pull 完发现提交历史上多了一堆分叉和合并节点才懵。1.3 SSH 免密配置与认证失败排查现在大部分 Git 平台都推荐用 HTTPS 配凭据管理器或者用 SSH 密钥认证。SSH 方式的优势是免密不用每次 push 都输密码也省去记个人访问令牌的麻烦。生成密钥并添加公钥的流程ssh-keygen -t ed25519 -C youremail.com一路回车会生成一对密钥默认在~/.ssh/目录下私钥文件id_ed25519公钥文件id_ed25519.pub。接着把公钥内容加到 Git 平台的 SSH keys 设置里cat ~/.ssh/id_ed25519.pub把输出的一整行复制到平台上保存然后验证一下是否配置成功ssh -T gitgithub.com如果看到类似 Hi username! Youve successfully authenticated 的输出说明认证已经通了。很多人卡在 SSH 认证失败上最常见的几个原因我挨个说~/.ssh目录或密钥文件权限不正确。私钥文件权限不能太宽松否则 SSH 客户端出于安全考虑会拒绝使用。修复命令chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519。公钥贴错了粘贴时多了空格或者少了 ssh-ed25519 前缀。干脆用cat命令输出CtrlA/CtrlC 全选复制最稳妥。网络环境无法直连 Git 平台导致超时。这种问题通常表现为ssh -T卡住很久然后报连接超时跟密钥没关系属于连通性问题需要检查网络环境。如果确认密钥没问题但还是认证失败建议先跑一下ssh -vT gitgithub.com看详细日志日志里会明确显示是用了哪个密钥文件、服务端接受还是拒绝排查效率比瞎猜高得多。2. 基础命令复盘理解暂存区才能不乱 commit基础命令很多人其实没有真正吃透。git add、git commit、git status、git log这四个命令天天用但如果你问add 到底把文件加到了哪里commit 又是在提交什么一部分人会说不上来。搞不清这一点后面学 amend 和 rebase 会感觉很飘因为你连 Git 的三个仓库都没在脑子里建起来。2.1 工作区、暂存区、本地仓库怎么区分Git 的核心模型是三个区域工作区你电脑磁盘上能看到的那些文件。你编辑代码、新建文件改动都发生在这里。暂存区也叫 index 或 stage。可以理解成购物车或者候车区你把想提交的文件git add进来就是告诉 Git 这些改动我准备要提交了。本地仓库.git目录里存的那一堆对象。git commit把暂存区的内容固化成一次永久快照这就是本地仓库里的一次提交。打个比方工作区是你厨房里的食材暂存区是备好的菜碟提交是按下快门拍下这一刻菜的最终形态存入相册。你只git add了某个文件这个文件的改动才会进入这盘菜没 add 的文件不管改得多大都不会进这次 commit。理解了这个模型你就知道一条日常准则每次 commit 前必然先跑git status和git diff确认要提交的内容完全符合预期再执行 commit。绝不该闭眼敲git add . git commit -m fix。2.2 高频基础命令速览与实际场景git status是最常用的命令没有之一。它告诉你当前工作区哪些文件改了、哪些进了暂存区、哪些还没被跟踪。我习惯每次准备 commit 前先看一眼有时候能发现漏掉的调试代码或者临时文件。git diff看的是工作区里还没暂存的改动内容。git add之后再想看将要提交的内容用git diff --staged。这个细节新手很容易混淆diff 不带参数时看的是已修改未暂存的部分不是全部改动。git log是看提交历史的常用的美化输出格式git log --oneline --graph --decorate --all--oneline每个提交只显示一行摘要--graph用 ASCII 画分支线--decorate显示分支和标签指向--all把所有分支的历史都显示出来。这几项搭配起来仓库的整体脉络一眼就清晰了。git commit建议养成分行写提交信息的习惯git commit -m feat: 添加用户登录接口 -m 登录接口支持验证码和手机号两种方式Token 有效期 2 小时两个-m分别对应提交信息的标题和正文。好的提交信息至少要说清楚做了什么和为什么做只写fix的提交信息等你三个月后再看绝对想不起来当时改了什么。git branch和git switch老版本是git checkout -b用来管理分支日常开新分支时git switch -c feature/user-login这个命令一步完成创建并切换分支。比起传统的git checkout -bgit switch的语义更清晰不太容易和文件恢复操作混淆。2.3 我在新人身上最常见的几个问题带人的过程中我发现基础命令用得混乱往往不是命令不会敲而是脑子里没建模。举几个高频翻车场景add 多了文件git add .把所有改动都加进暂存区包括不想提交的临时配置文件。解决方案是用git reset把某个文件从暂存区退出来文件本身的修改还在git restore --staged unwanted-file.txt注意不是git checkout -- file那是把文件内容都还原了改动直接丢失。新版推荐用git restore语义更明确。commit 之后发现漏了文件很多人会用git add missing-file git commit --amend来补这个我放到下一节详细讲但这里先剧透一个更好的习惯commit 之前先全局扫一眼有什么忘加的。回退操作一刀切git reset --hard HEAD~1很危险它会把工作区的文件改动也一并丢掉。对新手我更推荐先git stash或者用git reset --soft HEAD~1保留改动。清楚区别再动手比敲错了到处找恢复方案强得多。3. 提交写错了怎么办git commit --amend 的正确用法git commit --amend是绝大多数人遇到提交搞砸了时的第一反应但很多人不知道它到底做了什么。这里把原理和典型场景都讲透。3.1 amend 能改什么、不能改什么--amend的本质是用一个新的提交替换掉最后一个提交。它不会真的去修改旧提交Git 里的提交对象是不可变的而是基于最后一次提交的内容和新增的暂存区内容重新生成一个提交对象然后把这新提交挂在原来的位置上。所以它实际能做两件事修改最近一次提交的提交信息git commit --amend -m 新的提交信息把当前暂存区里的遗漏改动补进最后一次提交git add forgot-file.txt git commit --amend --no-edit--no-edit表示不修改提交信息只用暂存区内容生成新提交。这两种操作本质上都改变了提交的哈希值。原来那个旧的最后一次提交会从分支引用上消失变成悬空对象在 reflog 里还能找回。3.2 最典型的三个应用场景场景一提交信息有错别字或者越级了比如把 feat: 用户注册 写成了 fix: 修 bug。直接git commit --amend -m feat: 用户注册改掉干净利落。场景二提交完发现少了一个文件或者某个文件还有一行改动没加进去。把改动 add 进暂存区然后git commit --amend --no-edit这样提交内容和信息都保留了只是覆盖成新提交。场景三连续改了几次代码觉得这几个 commit 拆得太碎了想合并。这个其实更适合用后文的git rebase -i来做amend 只适合只动最近一条的场景。3.3 已推送的提交能不能 amend这是最关键的判断点。如果要修改的提交已经 push 到了远端共享分支最好不要直接 amend。因为 amend 会生成全新的提交哈希远端已有的旧提交就被晾在那里你git push时 Git 会拒绝这次推送提示 non-fast-forward 之类强制推送git push -f又会把别人的修改覆盖掉尤其在多人协作的分支上这容易把事情搞复杂。一个简单的评估标准这条提交有没有被别人 pull 过如果只有你自己在用那 amend 之后强制推送也没什么大碍如果是多人共享的分支宁可追加一个新提交来修正也别强行改写历史。原则在 git 世界里很简单——不要改写别人已经拿走的历史。我还想提一个组合技巧适合改动比较零散时使用git commit --amend --no-edit git push --force-with-lease--force-with-lease比--force安全得多。它会在推送前检查远端分支是否和你上次拉取的状态一致如果期间有别人的新提交推上来了它会拒绝推送避免把别人的提交顶掉。多人协作时急着修自己上一条提交这个方法算是损失最小的路径了。4. merge 还是 rebase两种合并思路与选择逻辑提到 rebase大部分人对它的印象就是危险慎用。这个印象的根源是它确实改变了历史但改变历史本身不是坏事关键是你改的是谁的历史。这一节我把 merge 和 rebase 的区别讲清楚再给出实际场景里的选择逻辑。4.1 merge 的真实含义git merge把两个分支的历史合并到一点最终会保留双方原有的提交顺序并额外生成一个合并提交merge commit这个提交有两个父提交。举个例子你在 main 上开了一个 feature 分支期间 main 上多了两个新提交feature 上多了三个新提交。git merge feature之后主线历史会呈现分叉再合并的形状——这是大部分图形化工具里看到的一进一出的交叉线。merge 的优点是不改写历史分支的每一次演化都被完整记录。缺点是当分支交叉频繁时历史图会变得很乱像一团毛线。很多仓库看 log 时全是交错线就是这个原因。4.2 rebase 如何变基git rebase做的事情是把你当前分支上的提交摘下来按顺序重新应用到另一个分支的最新提交之上。以同样场景为例在 feature 分支上执行git switch feature git rebase main效果是 feature 上的三个提交会搬到 main 最新提交的后面重新生成三个全新的提交对象。历史看起来变成一条直线main 的两个新提交在前feature 的三个提交紧随其后。这样历史非常干净利于代码走查和回溯。代价是原本在 feature 上存在的提交 SHA 值全变了原有的独立提交历史不见了所有提交看起来都像是今天刚产生的。4.3 怎么选冲突怎么办我的选择标准是这三条分支是自己的功能分支还没合回主分支别人也没有基于这个分支继续开发rebase 主分支保持功能分支和主分支的线性关系最后合并回去时整个历史很清爽。分支是多人共享的功能分支大家都在上面推提交别在共享分支上随意 rebase一旦有人基于旧历史继续提交就会出现难以收场的分叉。这种场景宁可用 merge 保留复杂度。合并回主分支时希望保留完整的当时做了什么的脉络用 merge它会记录分叉合入的时间点。冲突处理上merge 是一次性解决所有冲突rebase 则是一个提交一个提交地重放每个提交都可能报冲突解决完当前提交的冲突后执行git rebase --continue继续下一个直到全部重放完毕。如果中途发现搞不定可以git rebase --abort一键回到 rebase 前的状态整个过程是安全可回退的。关于冲突解决的重复劳动有一次我在 rebase 一个跨了三四个提交的分支每个提交的冲突都集中在同一个文件的同一个区域连续修了四次。当时真想切回 merge。后来习惯是先 commit 得细一点一个提交只做一件事重放冲突时通常每步都是独立逻辑解决起来反而快。这算是 rebase 反向推动你把提交切得更小的一个好处。5. 交互式 rebase把乱提交整理成一条线git rebase -i是 Git 里最有整理感的操作。它能合并提交、改提交信息、删除提交、调整提交顺序能力很强但也正因为强操作前做好备份、确认范围非常重要。5.1 什么时候需要整理提交历史典型场景是你在一个功能分支上吭哧吭哧写了七八个提交第三个提交是修第四行的 bug第六个提交是改回第三行的命名第八个提交删掉了第五个提交里加的调试代码。这种提交历史对功能合入没有价值反而让 reviewer 摸不着头脑。在合入主分支之前把这几条凌乱的提交整理成两三个逻辑完整的提交比如 feat: 用户登录接口、fix: 登录接口的为空校验review 起来非常舒服。整理提交历史就像给代码加注释不是给机器看的是给未来的阅读者看的。5.2 核心动作与完整示例看一个实际例子。假设当前分支有三个提交我想把这三个提交整理成一个git log --oneline a1b2c3d fix: 修正登录接口空指针问题 e4f5a6b feat: 登录接口补充验证码校验 7g8h9i0 feat: 添加登录接口执行git rebase -i HEAD~3Git 会打开编辑器内容大致是这样pick 7g8h9i0 feat: 添加登录接口 pick e4f5a6b feat: 登录接口补充验证码校验 pick a1b2c3d fix: 修正登录接口空指针问题从上到下是按时间排列的最下面是最近的提交。现在把后两行的pick改成squashpick 7g8h9i0 feat: 添加登录接口 squash e4f5a6b feat: 登录接口补充验证码校验 squash a1b2c3d fix: 修正登录接口空指针问题保存退出后编辑器再次打开让你重新编辑合并后的提交信息。最终历史变成了a1b2c3d (新哈希) feat: 添加登录接口三个提交合成了一个里面的内容完全没丢。除squash外还有几个常用动作pick保留该提交但可以靠调整行序来改变提交顺序。reword保留提交内容但允许修改它的提交信息。edit在该提交处停下允许修改文件内容然后git commit --amend git rebase --continue。drop直接删除该提交。谨慎使用删除前最好确认改动不在别的提交里有交集。5.3 危险操作保护措施我用了固定三步交互式 rebase 的水深不在于操作本身而在于你对要改动哪些提交的判断。分享一个我固定使用的三步法第一步改之前先给当前分支建一个备份分支。git switch -c backup/feature-before-rebase如果 rebase 后发现问题切回备份分支就知道原始状态长什么样。第二步确认 rebase 范围只在未推送的、且只有自己在做的提交上。判断方法是看这条分支有没有对应的远端同名分支、有没有别人也基于它开了新分支。有多个协作者在共用就不要动。第三步rebase 结束后用git log --oneline --graph手动核对一遍确认想要的提交顺序和内容都在。这个三步法救过我挺多次。印象比较深的一次是 rebase 时把两个提交的squash方向写反了把主提交 squash 进了修修补补的小提交里提交信息全乱套。要不是有备份分支想恢复得在 reflog 里翻半天。所以趁这里多说一句rebase 不可怕可怕的是不知道还能反悔。git reflog是你最后的后悔药它记录了 HEAD 的每次移动哪怕操作失误只要哈希还记得就能回到任意时刻的状态。6. 图形化工具与 IDE 集成让提交历史看得见最后说说图形化工具。很多人觉得命令行牛人都不屑于用 GUI其实不是的。实际开发里我会用 GUI 看历史图、做分支比对、可视化地处理部分冲突这些场景下图形化的效率反而更高。工具是拿来用的不用给自己设限。6.1 Git 自带的工具到底行不行装完 Git 就自带两个图形化工具gitk和git gui。gitk是一个历史查看器展示提交历史、分支分叉、文件改动。界面朴素但查看提交图这种需求完全够用。git gui则是一个简单的提交界面可以选择暂存文件、写提交信息、做 amend功能很基础。自带工具的价值在于零安装成本任何一台装了 Git 的机器都能用。缺点是性能和交互都比较古早大规模仓库里点开历史图会卡。我把它们当应急工具用专门应付别人电脑上啥都没有但要看历史的场景日常主用还是第三方工具。6.2 主流第三方 GUI 对比市面上主流的图形化 Git 客户端我列一张表直接对比工具平台支持突出优势典型短板SourceTreeWindows / macOS分支图清晰直观自带 Git Flow 支持启动偏慢有些版本界面略卡ForkWindows / macOS交互流畅提交对比体验好性能稳定没有 Linux 版GitKrakenWindows / macOS / Linux跨平台统一体验UI 现代化支持团队协作功能性能偏重部分高级功能要付费VS Code Git Graph全平台和编辑器集成一体查看历史图方便支持 rebase 操作可视化只适合查看和简单操作完整冲突处理还是靠编辑器如果你是团队协作比较频繁SourceTree 的图确实好看分支合并和暂存的操作逻辑也符合直觉。如果整体追求轻量和流畅Fork 一直是我个人用得最顺手的。GitKraken 适合跨平台团队和喜欢现代化界面的用户。但说实话图形化工具的核心价值不是替代命令行而是让你看见。命令行里git log --graph的那堆字符在 GUI 里就是一根根清晰的分支线。你一眼能看出哪些提交是合并节点哪些是改动主体这个感知能力对排错和 review 都有用。建议不管用哪个工具都要定期打开看看你仓库的历史图长什么样。6.3 在 IDEA 里拉取项目与日常操作很多新人的第一次 Git 操作不是命令行而是在 IDE 里完成的。以 IDEA 为例从远程拉取项目这个动作走的是 Team 菜单或者启动界面的 Get from VCS。用 IDEA 拉取 Git 项目时有几个容易踩坑的细节Clone URL 要正确。GitHub 上复制项目地址时要选 SSH 形式还是 HTTPS 形式取决于你的认证方式。SSH 配置好了用 SSH 地址免密最省心HTTPS 地址则要配合 IDEA 的凭据管理器首次拉取会弹窗让你登录。拉取的时候 IDEA 会问分支一般选默认的 main 或 master。拉完之后右下角的分支按钮可以随时切换分支开发时记得从最新的主干切出自己的功能分支别直接在主干上改。IDEA 里整合了git add、commit、push、rebase、merge等操作。尤其是 amend在 Commit 面板的右侧有一个小铅笔图标可以让Commit变成Amend Commit新手用这个图形化的 amend 比敲命令行直观很多。遇到冲突时IDEA 的冲突解决器比手搓终端友好太多。左边是你的版本右边是别人改的版本中间是合并结果。逐条接受或拒绝处理完保存文件IDEA 会自动标记冲突已解决。其实 IDE 集成的 Git 能力已经很全面日常增删改查完全覆盖。对刚入门的同学我甚至建议先在 IDE 里把 Git 的日常操作跑顺了再用命令行去深化理解。两条路不冲突反而互补。图形化工具也好、IDE 集成也好它们帮你解决的是看和点的问题但 Git 最核心的概念——提交对象、引用的移动、历史的分叉与合并——还是得靠命令行去操作和理解。当你用多了脑子里自然就会建立起 Git 的对象模型那时候你会发现所有命令其实都是同一套逻辑的变形。我个人用了这么多年 Git 下来最大的体会是别把 Git 当一门背命令的技能它更像一套分布式版本的思维方式。你在 commit 之间切换、用 rebase 调整历史、用 GUI 观察分支走向本质上都是在和快照与引用打交道。把这个模型装进脑子无论它换什么工具、什么平台你都不会慌。希望这篇整理能对正在学习 Git 的你有点实际帮助。
Git 实战指南：从基础提交到分支整理与历史重写
最近在带一个刚入行的同事发现他 Git 用得挺顺add、commit、push 都敲得飞起。但等到代码写岔了要回退、提交信息写错了要改、或者需要把几个乱糟糟的提交整理成一个的时候他就卡住了。鼠标在终端里犹豫半天最后还是打开网盘里存的那份Git 命令大全翻半天也找不到对症的那一条。这其实是挺多人的真实状态基础命令会了但也只是会按回车遇到稍微绕一点的提交整理需求就两眼一黑。图形化工具倒是装了好几个但大多时间也只是用来看看提交记录本质上还是命令行操作。这篇文章我想从实操角度把这些事从头到尾捋一遍。内容覆盖 Git 的安装与初始化、最常用的基础命令、用 amend 修补提交、用 merge 和 rebase 整理分支以及交互式 rebase 的进阶玩法最后再聊几款常见的图形化工具和 IDE 集成。我尽量不用教科书式的讲法而是给你一套我自己日常开发中确实在用的操作逻辑。适合刚接触 Git 的新人也适合工作了一两年但一直没系统整理过 Git 知识的人。1. 先把环境备好Git 安装与初次配置很多人以为装完 Git 就算装好了结果第一次 commit 就报错第一次 push 就认证失败然后跑到群里问为什么。其实这些问题大多不是 Git 本身的问题而是环境初始化和认证配置没做好。1.1 各平台安装 Git 的实操方式Windows 上最省事的做法就是去官网下 Git for Windows 的安装包一路 Next 就能装上。需要注意的一个细节是安装过程中Adjusting your PATH environment这一步建议选Git from the command line and also from 3rd-party software。这个选项会把 Git 的核心命令加进系统 PATH保证你在任何终端窗口里输入 git 都能直接用而不是只能在 Git Bash 里用。另一个常见选项是换行符转换Checkout Windows-style, commit Unix-style line endings 对大多数跨平台项目来说是最不会出事的默认项。macOS 用户我建议直接用 Homebrew 装brew install gitHomebrew 装的版本通常比系统自带的旧版要新不少而且后续升级也省事一条brew upgrade git就搞定。如果你没装 Homebrew去官网下载 macOS 版安装包也可以但版本更新就得手动来稍微麻烦。Linux 用户看发行版Debian/Ubuntu 系列sudo apt update sudo apt install gitCentOS/RHEL 系列sudo yum install git装完后终端里跑一下git --version确认版本。如果看到一个 2.3x 以上的版本号环境就没问题了。这里有个小建议别在过老的 Git 版本上停留2024 年了Git 2.40 以上的版本对 SSH 签名、ref 格式兼容性都友好很多旧版本在处理一些新仓库格式时容易出现莫名其妙的问题。1.2 首次运行前的必备配置Git 装好后的第一件事不是 clone 代码而是告诉 Git 你是谁。这步不做commit 的时候 Git 会报用户名和邮箱缺失或者直接用系统自动推测的错误信息提交上去后面追查历史时很尴尬。git config --global user.name 你的名字 git config --global user.email youremail.com注意这里邮箱最好填你能收到邮件的真实地址很多 Git 平台的提交记录会关联到这个邮箱。以前见过有人随手填了个 testtest.com后来代码出问题想联系作者对着提交记录干瞪眼。除了用户名邮箱我建议顺手把默认编辑器改掉。Git 在某些操作比如 commit 不带 -m、交互式 rebase时会调用默认编辑器让你输入内容默认的 Vim 对很多不熟悉命令行编辑器的同学是一道坎git config --global core.editor code --wait如果你用 VS Code这条命令会把默认编辑器设置为 VS Code输入提交信息时直接用熟悉的编辑器体验顺滑很多。不用 VS Code 的话也可以设置成记事本或者 Sublime Text只要支持等待关闭后再继续这个特性就行。还有一个容易被忽略的配置是pull.rebase。默认情况下git pull走的是 merge 策略会额外产生一个 merge commit。我个人偏向把 pull 设置为 rebase 模式git config --global pull.rebase false这行我没有写死建议值想说明的是这个配置完全看团队协作风格。你在团队里如果习惯了git pull后干干净净地继续开发可以设成true如果你喜欢保留合并痕迹就保持默认的false。核心是要知道有这么个开关而不是等 pull 完发现提交历史上多了一堆分叉和合并节点才懵。1.3 SSH 免密配置与认证失败排查现在大部分 Git 平台都推荐用 HTTPS 配凭据管理器或者用 SSH 密钥认证。SSH 方式的优势是免密不用每次 push 都输密码也省去记个人访问令牌的麻烦。生成密钥并添加公钥的流程ssh-keygen -t ed25519 -C youremail.com一路回车会生成一对密钥默认在~/.ssh/目录下私钥文件id_ed25519公钥文件id_ed25519.pub。接着把公钥内容加到 Git 平台的 SSH keys 设置里cat ~/.ssh/id_ed25519.pub把输出的一整行复制到平台上保存然后验证一下是否配置成功ssh -T gitgithub.com如果看到类似 Hi username! Youve successfully authenticated 的输出说明认证已经通了。很多人卡在 SSH 认证失败上最常见的几个原因我挨个说~/.ssh目录或密钥文件权限不正确。私钥文件权限不能太宽松否则 SSH 客户端出于安全考虑会拒绝使用。修复命令chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519。公钥贴错了粘贴时多了空格或者少了 ssh-ed25519 前缀。干脆用cat命令输出CtrlA/CtrlC 全选复制最稳妥。网络环境无法直连 Git 平台导致超时。这种问题通常表现为ssh -T卡住很久然后报连接超时跟密钥没关系属于连通性问题需要检查网络环境。如果确认密钥没问题但还是认证失败建议先跑一下ssh -vT gitgithub.com看详细日志日志里会明确显示是用了哪个密钥文件、服务端接受还是拒绝排查效率比瞎猜高得多。2. 基础命令复盘理解暂存区才能不乱 commit基础命令很多人其实没有真正吃透。git add、git commit、git status、git log这四个命令天天用但如果你问add 到底把文件加到了哪里commit 又是在提交什么一部分人会说不上来。搞不清这一点后面学 amend 和 rebase 会感觉很飘因为你连 Git 的三个仓库都没在脑子里建起来。2.1 工作区、暂存区、本地仓库怎么区分Git 的核心模型是三个区域工作区你电脑磁盘上能看到的那些文件。你编辑代码、新建文件改动都发生在这里。暂存区也叫 index 或 stage。可以理解成购物车或者候车区你把想提交的文件git add进来就是告诉 Git 这些改动我准备要提交了。本地仓库.git目录里存的那一堆对象。git commit把暂存区的内容固化成一次永久快照这就是本地仓库里的一次提交。打个比方工作区是你厨房里的食材暂存区是备好的菜碟提交是按下快门拍下这一刻菜的最终形态存入相册。你只git add了某个文件这个文件的改动才会进入这盘菜没 add 的文件不管改得多大都不会进这次 commit。理解了这个模型你就知道一条日常准则每次 commit 前必然先跑git status和git diff确认要提交的内容完全符合预期再执行 commit。绝不该闭眼敲git add . git commit -m fix。2.2 高频基础命令速览与实际场景git status是最常用的命令没有之一。它告诉你当前工作区哪些文件改了、哪些进了暂存区、哪些还没被跟踪。我习惯每次准备 commit 前先看一眼有时候能发现漏掉的调试代码或者临时文件。git diff看的是工作区里还没暂存的改动内容。git add之后再想看将要提交的内容用git diff --staged。这个细节新手很容易混淆diff 不带参数时看的是已修改未暂存的部分不是全部改动。git log是看提交历史的常用的美化输出格式git log --oneline --graph --decorate --all--oneline每个提交只显示一行摘要--graph用 ASCII 画分支线--decorate显示分支和标签指向--all把所有分支的历史都显示出来。这几项搭配起来仓库的整体脉络一眼就清晰了。git commit建议养成分行写提交信息的习惯git commit -m feat: 添加用户登录接口 -m 登录接口支持验证码和手机号两种方式Token 有效期 2 小时两个-m分别对应提交信息的标题和正文。好的提交信息至少要说清楚做了什么和为什么做只写fix的提交信息等你三个月后再看绝对想不起来当时改了什么。git branch和git switch老版本是git checkout -b用来管理分支日常开新分支时git switch -c feature/user-login这个命令一步完成创建并切换分支。比起传统的git checkout -bgit switch的语义更清晰不太容易和文件恢复操作混淆。2.3 我在新人身上最常见的几个问题带人的过程中我发现基础命令用得混乱往往不是命令不会敲而是脑子里没建模。举几个高频翻车场景add 多了文件git add .把所有改动都加进暂存区包括不想提交的临时配置文件。解决方案是用git reset把某个文件从暂存区退出来文件本身的修改还在git restore --staged unwanted-file.txt注意不是git checkout -- file那是把文件内容都还原了改动直接丢失。新版推荐用git restore语义更明确。commit 之后发现漏了文件很多人会用git add missing-file git commit --amend来补这个我放到下一节详细讲但这里先剧透一个更好的习惯commit 之前先全局扫一眼有什么忘加的。回退操作一刀切git reset --hard HEAD~1很危险它会把工作区的文件改动也一并丢掉。对新手我更推荐先git stash或者用git reset --soft HEAD~1保留改动。清楚区别再动手比敲错了到处找恢复方案强得多。3. 提交写错了怎么办git commit --amend 的正确用法git commit --amend是绝大多数人遇到提交搞砸了时的第一反应但很多人不知道它到底做了什么。这里把原理和典型场景都讲透。3.1 amend 能改什么、不能改什么--amend的本质是用一个新的提交替换掉最后一个提交。它不会真的去修改旧提交Git 里的提交对象是不可变的而是基于最后一次提交的内容和新增的暂存区内容重新生成一个提交对象然后把这新提交挂在原来的位置上。所以它实际能做两件事修改最近一次提交的提交信息git commit --amend -m 新的提交信息把当前暂存区里的遗漏改动补进最后一次提交git add forgot-file.txt git commit --amend --no-edit--no-edit表示不修改提交信息只用暂存区内容生成新提交。这两种操作本质上都改变了提交的哈希值。原来那个旧的最后一次提交会从分支引用上消失变成悬空对象在 reflog 里还能找回。3.2 最典型的三个应用场景场景一提交信息有错别字或者越级了比如把 feat: 用户注册 写成了 fix: 修 bug。直接git commit --amend -m feat: 用户注册改掉干净利落。场景二提交完发现少了一个文件或者某个文件还有一行改动没加进去。把改动 add 进暂存区然后git commit --amend --no-edit这样提交内容和信息都保留了只是覆盖成新提交。场景三连续改了几次代码觉得这几个 commit 拆得太碎了想合并。这个其实更适合用后文的git rebase -i来做amend 只适合只动最近一条的场景。3.3 已推送的提交能不能 amend这是最关键的判断点。如果要修改的提交已经 push 到了远端共享分支最好不要直接 amend。因为 amend 会生成全新的提交哈希远端已有的旧提交就被晾在那里你git push时 Git 会拒绝这次推送提示 non-fast-forward 之类强制推送git push -f又会把别人的修改覆盖掉尤其在多人协作的分支上这容易把事情搞复杂。一个简单的评估标准这条提交有没有被别人 pull 过如果只有你自己在用那 amend 之后强制推送也没什么大碍如果是多人共享的分支宁可追加一个新提交来修正也别强行改写历史。原则在 git 世界里很简单——不要改写别人已经拿走的历史。我还想提一个组合技巧适合改动比较零散时使用git commit --amend --no-edit git push --force-with-lease--force-with-lease比--force安全得多。它会在推送前检查远端分支是否和你上次拉取的状态一致如果期间有别人的新提交推上来了它会拒绝推送避免把别人的提交顶掉。多人协作时急着修自己上一条提交这个方法算是损失最小的路径了。4. merge 还是 rebase两种合并思路与选择逻辑提到 rebase大部分人对它的印象就是危险慎用。这个印象的根源是它确实改变了历史但改变历史本身不是坏事关键是你改的是谁的历史。这一节我把 merge 和 rebase 的区别讲清楚再给出实际场景里的选择逻辑。4.1 merge 的真实含义git merge把两个分支的历史合并到一点最终会保留双方原有的提交顺序并额外生成一个合并提交merge commit这个提交有两个父提交。举个例子你在 main 上开了一个 feature 分支期间 main 上多了两个新提交feature 上多了三个新提交。git merge feature之后主线历史会呈现分叉再合并的形状——这是大部分图形化工具里看到的一进一出的交叉线。merge 的优点是不改写历史分支的每一次演化都被完整记录。缺点是当分支交叉频繁时历史图会变得很乱像一团毛线。很多仓库看 log 时全是交错线就是这个原因。4.2 rebase 如何变基git rebase做的事情是把你当前分支上的提交摘下来按顺序重新应用到另一个分支的最新提交之上。以同样场景为例在 feature 分支上执行git switch feature git rebase main效果是 feature 上的三个提交会搬到 main 最新提交的后面重新生成三个全新的提交对象。历史看起来变成一条直线main 的两个新提交在前feature 的三个提交紧随其后。这样历史非常干净利于代码走查和回溯。代价是原本在 feature 上存在的提交 SHA 值全变了原有的独立提交历史不见了所有提交看起来都像是今天刚产生的。4.3 怎么选冲突怎么办我的选择标准是这三条分支是自己的功能分支还没合回主分支别人也没有基于这个分支继续开发rebase 主分支保持功能分支和主分支的线性关系最后合并回去时整个历史很清爽。分支是多人共享的功能分支大家都在上面推提交别在共享分支上随意 rebase一旦有人基于旧历史继续提交就会出现难以收场的分叉。这种场景宁可用 merge 保留复杂度。合并回主分支时希望保留完整的当时做了什么的脉络用 merge它会记录分叉合入的时间点。冲突处理上merge 是一次性解决所有冲突rebase 则是一个提交一个提交地重放每个提交都可能报冲突解决完当前提交的冲突后执行git rebase --continue继续下一个直到全部重放完毕。如果中途发现搞不定可以git rebase --abort一键回到 rebase 前的状态整个过程是安全可回退的。关于冲突解决的重复劳动有一次我在 rebase 一个跨了三四个提交的分支每个提交的冲突都集中在同一个文件的同一个区域连续修了四次。当时真想切回 merge。后来习惯是先 commit 得细一点一个提交只做一件事重放冲突时通常每步都是独立逻辑解决起来反而快。这算是 rebase 反向推动你把提交切得更小的一个好处。5. 交互式 rebase把乱提交整理成一条线git rebase -i是 Git 里最有整理感的操作。它能合并提交、改提交信息、删除提交、调整提交顺序能力很强但也正因为强操作前做好备份、确认范围非常重要。5.1 什么时候需要整理提交历史典型场景是你在一个功能分支上吭哧吭哧写了七八个提交第三个提交是修第四行的 bug第六个提交是改回第三行的命名第八个提交删掉了第五个提交里加的调试代码。这种提交历史对功能合入没有价值反而让 reviewer 摸不着头脑。在合入主分支之前把这几条凌乱的提交整理成两三个逻辑完整的提交比如 feat: 用户登录接口、fix: 登录接口的为空校验review 起来非常舒服。整理提交历史就像给代码加注释不是给机器看的是给未来的阅读者看的。5.2 核心动作与完整示例看一个实际例子。假设当前分支有三个提交我想把这三个提交整理成一个git log --oneline a1b2c3d fix: 修正登录接口空指针问题 e4f5a6b feat: 登录接口补充验证码校验 7g8h9i0 feat: 添加登录接口执行git rebase -i HEAD~3Git 会打开编辑器内容大致是这样pick 7g8h9i0 feat: 添加登录接口 pick e4f5a6b feat: 登录接口补充验证码校验 pick a1b2c3d fix: 修正登录接口空指针问题从上到下是按时间排列的最下面是最近的提交。现在把后两行的pick改成squashpick 7g8h9i0 feat: 添加登录接口 squash e4f5a6b feat: 登录接口补充验证码校验 squash a1b2c3d fix: 修正登录接口空指针问题保存退出后编辑器再次打开让你重新编辑合并后的提交信息。最终历史变成了a1b2c3d (新哈希) feat: 添加登录接口三个提交合成了一个里面的内容完全没丢。除squash外还有几个常用动作pick保留该提交但可以靠调整行序来改变提交顺序。reword保留提交内容但允许修改它的提交信息。edit在该提交处停下允许修改文件内容然后git commit --amend git rebase --continue。drop直接删除该提交。谨慎使用删除前最好确认改动不在别的提交里有交集。5.3 危险操作保护措施我用了固定三步交互式 rebase 的水深不在于操作本身而在于你对要改动哪些提交的判断。分享一个我固定使用的三步法第一步改之前先给当前分支建一个备份分支。git switch -c backup/feature-before-rebase如果 rebase 后发现问题切回备份分支就知道原始状态长什么样。第二步确认 rebase 范围只在未推送的、且只有自己在做的提交上。判断方法是看这条分支有没有对应的远端同名分支、有没有别人也基于它开了新分支。有多个协作者在共用就不要动。第三步rebase 结束后用git log --oneline --graph手动核对一遍确认想要的提交顺序和内容都在。这个三步法救过我挺多次。印象比较深的一次是 rebase 时把两个提交的squash方向写反了把主提交 squash 进了修修补补的小提交里提交信息全乱套。要不是有备份分支想恢复得在 reflog 里翻半天。所以趁这里多说一句rebase 不可怕可怕的是不知道还能反悔。git reflog是你最后的后悔药它记录了 HEAD 的每次移动哪怕操作失误只要哈希还记得就能回到任意时刻的状态。6. 图形化工具与 IDE 集成让提交历史看得见最后说说图形化工具。很多人觉得命令行牛人都不屑于用 GUI其实不是的。实际开发里我会用 GUI 看历史图、做分支比对、可视化地处理部分冲突这些场景下图形化的效率反而更高。工具是拿来用的不用给自己设限。6.1 Git 自带的工具到底行不行装完 Git 就自带两个图形化工具gitk和git gui。gitk是一个历史查看器展示提交历史、分支分叉、文件改动。界面朴素但查看提交图这种需求完全够用。git gui则是一个简单的提交界面可以选择暂存文件、写提交信息、做 amend功能很基础。自带工具的价值在于零安装成本任何一台装了 Git 的机器都能用。缺点是性能和交互都比较古早大规模仓库里点开历史图会卡。我把它们当应急工具用专门应付别人电脑上啥都没有但要看历史的场景日常主用还是第三方工具。6.2 主流第三方 GUI 对比市面上主流的图形化 Git 客户端我列一张表直接对比工具平台支持突出优势典型短板SourceTreeWindows / macOS分支图清晰直观自带 Git Flow 支持启动偏慢有些版本界面略卡ForkWindows / macOS交互流畅提交对比体验好性能稳定没有 Linux 版GitKrakenWindows / macOS / Linux跨平台统一体验UI 现代化支持团队协作功能性能偏重部分高级功能要付费VS Code Git Graph全平台和编辑器集成一体查看历史图方便支持 rebase 操作可视化只适合查看和简单操作完整冲突处理还是靠编辑器如果你是团队协作比较频繁SourceTree 的图确实好看分支合并和暂存的操作逻辑也符合直觉。如果整体追求轻量和流畅Fork 一直是我个人用得最顺手的。GitKraken 适合跨平台团队和喜欢现代化界面的用户。但说实话图形化工具的核心价值不是替代命令行而是让你看见。命令行里git log --graph的那堆字符在 GUI 里就是一根根清晰的分支线。你一眼能看出哪些提交是合并节点哪些是改动主体这个感知能力对排错和 review 都有用。建议不管用哪个工具都要定期打开看看你仓库的历史图长什么样。6.3 在 IDEA 里拉取项目与日常操作很多新人的第一次 Git 操作不是命令行而是在 IDE 里完成的。以 IDEA 为例从远程拉取项目这个动作走的是 Team 菜单或者启动界面的 Get from VCS。用 IDEA 拉取 Git 项目时有几个容易踩坑的细节Clone URL 要正确。GitHub 上复制项目地址时要选 SSH 形式还是 HTTPS 形式取决于你的认证方式。SSH 配置好了用 SSH 地址免密最省心HTTPS 地址则要配合 IDEA 的凭据管理器首次拉取会弹窗让你登录。拉取的时候 IDEA 会问分支一般选默认的 main 或 master。拉完之后右下角的分支按钮可以随时切换分支开发时记得从最新的主干切出自己的功能分支别直接在主干上改。IDEA 里整合了git add、commit、push、rebase、merge等操作。尤其是 amend在 Commit 面板的右侧有一个小铅笔图标可以让Commit变成Amend Commit新手用这个图形化的 amend 比敲命令行直观很多。遇到冲突时IDEA 的冲突解决器比手搓终端友好太多。左边是你的版本右边是别人改的版本中间是合并结果。逐条接受或拒绝处理完保存文件IDEA 会自动标记冲突已解决。其实 IDE 集成的 Git 能力已经很全面日常增删改查完全覆盖。对刚入门的同学我甚至建议先在 IDE 里把 Git 的日常操作跑顺了再用命令行去深化理解。两条路不冲突反而互补。图形化工具也好、IDE 集成也好它们帮你解决的是看和点的问题但 Git 最核心的概念——提交对象、引用的移动、历史的分叉与合并——还是得靠命令行去操作和理解。当你用多了脑子里自然就会建立起 Git 的对象模型那时候你会发现所有命令其实都是同一套逻辑的变形。我个人用了这么多年 Git 下来最大的体会是别把 Git 当一门背命令的技能它更像一套分布式版本的思维方式。你在 commit 之间切换、用 rebase 调整历史、用 GUI 观察分支走向本质上都是在和快照与引用打交道。把这个模型装进脑子无论它换什么工具、什么平台你都不会慌。希望这篇整理能对正在学习 Git 的你有点实际帮助。
