Git命令行实战：从安装配置到冲突回退与疑难排查

实际带过几个新人之后我发现一个规律用图形界面操作Git的同学通常能应付日常提交推送但一遇到merge冲突、误回退、分支搞乱这类事后补救就发懵习惯用命令行的人反而很少慌因为命令行的每一步操作都是明确的、可预期的出问题也更容易定位。这篇不是命令字典式的罗列我把工作里真正高频的Git命令按操作场景拆开讲覆盖安装配置、SSH免密、日常提交、分支合并、merge回退、.gitignore失效、认证失败排查这些常见问题适合刚接触Git的新手也适合一直用GUI但想补上命令行这块短板的同学。1. 为什么要用命令行操作Git一次事故引发的习惯转变1.1 图形界面和命令行的真实差距先讲我自己的经历。早年在IDE里用Git插件一切看起来都很美好直到有一次我手滑在develop分支上提交了十几个文件里面混了两个还没写完的配置文件。我想把这两个文件从提交里拆出来在IDE里点了半天找不到该点哪里最后靠同事帮忙才处理掉。那次之后我花了一晚上把Git命令行过了一遍之后再也没有因为界面里找不到某个操作而卡住。图形界面的问题在于它把Git的底层逻辑藏起来了。你看到的是一堆按钮但Git本质上是一个管理文件快照的工具每个操作背后都有明确的对象和指针变化。用命令行操作你每敲一条命令心里很清楚这条命令在改动什么。而且命令行在不同操作系统、不同IDE之间是通用的今天你用IntelliJ Idea明天换VSCode后天去服务器上改代码命令行技能全都能用上。再说一个很多人忽略的点自动化。CI/CD脚本、数据库迁移、服务器部署这些场景没有图形界面给你点只有命令行。平时习惯用命令行到了这些场景才不会慌。1.2 理解Git的三个核心区域命令才有意义命令行Git学起来难是因为很多教程上来就让你背命令不解释命令背后的逻辑。其实Git只需理解一件事文件在三个区域之间移动。工作区是你电脑上看到的真实文件目录用来编辑代码暂存区Index是提交前的缓冲区用git add把工作区的改动放进来版本库Repository是Git真正存储所有提交历史的地方用git commit把暂存区的内容固化成一次历史记录。这三个区域对应了最核心的命令组合git add -A # 工作区 - 暂存区 git commit -m 提交说明 # 暂存区 - 版本库 git push origin 分支名 # 本地版本库 - 远程版本库这个模型想通之后很多问题自然就理解了。比如你git add之后又改了文件commit提交的其实是你add那一刻的内容后面改的还需要重新add。再比如git checkout -- 文件名为什么能丢弃工作区修改因为它就是用版本库里的版本覆盖当前文件。所有命令背后都是这三个区域的状态流转。2. 从零开始安装、首次全局配置与SSH免密2.1 安装后的三个必做配置Git装好后第一件事不是clone代码而是设置身份。这一步很多人跳过结果提交记录里全是unknown代码评审的时候都不知道谁改的。# 配置提交者姓名和邮箱这里用全局配置对所有仓库生效 git config --global user.name 你的名字 git config --global user.email your_emailexample.com建议同时配置默认分支名和换行符处理。默认分支名配成main能避免每次初始化仓库都要手动改git config --global init.defaultBranch main # Windows同学强烈建议配这个防止不同系统间换行符导致的文件变更 git config --global core.autocrlf truecore.autocrlf这个配置值得单独讲讲。Windows回车的编码是CRLFLinux和macOS是LF。如果没有统一处理你拉下来的代码可能因为换行符不同被判定为全部修改diff乱成一团。配置成true之后Git会在提交时自动把CRLF转成LF检出时转回CRLF大部分情况下能避免这类噪音。配置完了可以验证一下git config --list2.2 SSH密钥配置与多账号免密登录日常工作中用HTTPS方式clone代码每次都要输密码很影响效率。SSH密钥方式配好之后一劳永逸。我平时在Gitee和GitHub上都用SSH配置流程是一样的。先检查本地是否已有密钥ls -al ~/.ssh/如果看到id_rsa和id_rsa.pub说明之前生成过可以直接复用。没有就生成一份ssh-keygen -t rsa -b 4096 -C your_emailexample.com执行后一路回车即可默认生成到~/.ssh/id_rsa。注意不要额外设置口令密码否则后面每次push都要输SSH密钥口令免密就变成换个方式输入密码了。然后查看公钥内容复制到代码平台的SSH公钥设置里cat ~/.ssh/id_rsa.pub在Gitee或GitHub的设置页面找到SSH公钥把输出粘贴进去标题随便填。配置完成后验证连通性ssh -T gitgitee.com # 如果看到 Hi xxx! Youve successfully authenticated说明配置成功首次SSH连远程仓库会提示确认主机指纹输入 yes 回车就行这个指纹会记录到~/.ssh/known_hosts。如果你连着多台代码服务器这个文件就是它们指纹的清单。2.3 远程仓库关联与clone方式的选择新项目从零开始有两种接入方式。一种是直接在远程仓库建好项目然后clone到本地git clone gitgitee.com:用户名/仓库名.git另一种是本地已有项目需要关联远程仓库git remote add origin gitgitee.com:用户名/仓库名.git git push -u origin main-u参数的意思是关联远程分支。执行之后后续直接git push或git pullGit就知道你要和哪个远程分支同步不用每次写全命令。一个本地仓库可以关联多个远程源用git remote -v查看现有配置git remote rename old new可以给远程源改名比如把默认的origin改成gitee方便区分。3. 每天必用的高频命令提交、推送、拉取与分支操作3.1 提交相关add、commit、reset的配合最核心的日常操作就是提交代码。这里我想重点讲一下 reset 的三种模式因为工作里经常有人用错。场景是这样的你提交了一次commit发现提交信息写错了或者有几个文件不该提交想撤回来重新整理。三个模式的区别在于撤回到哪一步# 回到暂存区状态保留修改需要重新add git reset --soft HEAD~1 # 回到工作区状态保留修改但不保留add标记 git reset HEAD~1 # 丢弃修改直接回到上一个提交的状态危险操作谨慎使用 git reset --hard HEAD~1--soft是最常用也最安全的撤回方式适合commit说明写错了想重写commit里漏了文件想补进去这类场景。顺序乱掉的提交可以用git commit --amend修正最近一次提交说明或补充文件git add 漏掉的文件 git commit --amend -m 修正后的提交说明注意--amend会改写提交记录如果这个提交已经push到远程且是多人协作分支慎用会造成历史不一致。3.2 分支操作创建、切换、合并、删除分支是Git多工作流的基石。我日常工作流的做法是每个人从develop拉出自己的功能分支开发完合并回去。高频分支命令如下# 创建并切换分支 git checkout -b feature/xxx # 查看本地分支和远程分支 git branch git branch -r # 切换到某个分支 git checkout develop # 删除本地分支分支已合并时用 git branch -d feature/xxx # 强制删除本地分支分支未合并但有把握时用 git branch -D feature/xxx创建分支这个操作有新旧两种写法git checkout -b是最传统的Git 2.23 之后推荐用git switch -c语义更明确不容易和切换分支、恢复文件混在一起。不过老仓库和很多教程还广泛用checkout两个我都会日常主要用git switch。分支合并是工作里最容易出状况的环节。合并前先把两个分支都更新到最新git checkout develop git pull origin develop # 或 git pull git merge feature/xxx如果合并时提示冲突不必慌。Git会在冲突文件里用标记标出两个分支的内容你手动编辑成最终想要的版本然后重新add、commit即可git add 有冲突的文件 git merge --continue3.3 pull与fetch的区别为什么推荐先fetch再merge新手最常见的误区是以为git pull就是把远程代码拉下来这么简单。实际上git pull是两个操作的组合先git fetch把远程的修改拉到本地的远程跟踪分支如origin/develop再执行merge合并到当前分支。理解了这一点很多诡异问题都有了解释。比如你本地develop有个commit没push远程develop也有别人的新commit直接git pull大概率会告诉你需要合并或变基甚至提示冲突。因为你本地和远程在同一个分叉点上有两段不同的历史Git不知道该用哪段需要你决定怎么合。我的习惯是不直接用git pull而是分开执行git fetch origin git log --oneline HEAD..origin/develop # 查看远程比本地多出的提交 git merge origin/developHEAD..origin/develop这个区间语法值得记一下它表示从现在本地HEAD的位置到远程分支之间这段提交。先看清单再合并至少知道自己会引进哪些改动。想丢弃本地和远程差异、完全对齐远程可以用git reset --hard origin/develop这个命令会丢掉本地未push的commit和所有工作区改动执行之前想清楚。4. 合并不慌冲突排查、merge回退与误删恢复4.1 merge冲突的完整排查链路冲突是所有Git新手最怕的事但形成自己的排查方法之后其实很有规律。我总结的排查路线是这样的。先看冲突发生在哪些文件git status在Unmerged paths那一节会列出冲突文件。打开文件会看到、、三个标记 HEAD 这里是你当前分支的代码 这里是另一个分支的代码 feature/xxx以上是当前分支HEAD的内容以下是合并进来的分支的内容。处理方式无非几种保留当前分支的保留合并分支的两段都保留或者重写成全新的逻辑。编辑完把标记行删掉然后git add 冲突文件 git merge --continueGit会打开提交信息编辑器让你确认合并说明保存关闭即可。这里分享一个经验解决复杂冲突别直接在冲突标记里改代码因为你只能看到片段看不到上下文。我习惯先搜索定位所有冲突点然后逐个打开源码文件在完整上下文里解决冲突解决完再重新编译运行验证最后统一add。4.2 合并错了想回退merge的revert与reset到底怎么选工作里合并merge是常态合并错了想回退也时有发生。很多人一上来就git reset --hard回退如果是自己的私有分支还好在共享分支上这么干会直接改写远程历史队友一拉代码历史对不上场面很难收拾。正确思路是区分场景。场景一合并后还没push到远程。这个最安全直接reset到合并前的位置git reset --hard HEAD~1场景二合并已经push到远程别人可能已经基于这个合并提交拉了分支。这时候不能reset改写历史要新增一个反操作的提交git revert -m 1 合并提交的版本号-m 1表示保留合并之前的第一个父提交即撤销这次合并且在历史上留下一笔记录一查便知。这是我在Idea里收到如何回退merge操作这个问题后从命令行方式总结出的结论在共享分支上回退合并的唯一安全方式就是revert而不是reset。需要注意的是revert之后那个功能分支的代码后续想重新合并会有一些历史合并记录干扰需要先在功能分支上revert掉之前那个 revert 提交再重新merge。这个逻辑绕了点我在下面单独列一下步骤# 先切到功能分支撤销上次的revert git checkout feature/xxx git revert 上一次revert的版本号 # 再回到目标分支重新合并 git checkout develop git merge feature/xxx4.3 reflog误删分支和误reset的后悔药Git最容易被低估的命令是git reflog。它记录的是Git引用HEAD、分支等每次变化的痕迹相当于一份操作流水账。我帮人找回过很多次误删的分支和误reset丢掉的提交。场景你删除了一个功能分支过了几个小时发现上面的代码很重要就是想恢复。这时候git branch已经看不到它了但分支最后一次指向的commit还悬在医院里没被回收用reflog可以找到git reflog执行后能看到一长串历史操作每行是一行 hash、一个HEAD位置。找到删除前那次checkout或merge对应的hash然后基于它重建分支git branch new-branch-name 目标hash如果是误reset --hard丢了本地未提交的改动相同思路用reflog找到执行reset之前那次提交的位置git reset --hard 目标hash切回去。用reflog有一点要注意系统定期会清理过期记录默认大概90天发现误操作尽早恢复别拖太久。5. 高频疑难排查.gitignore失效、SSH认证失败与目录泄露5.1 .gitignore配了不生效根因和正确的生效姿势我明明在 .gitignore 里写了忽略规则git status 还是显示这个文件这个问题几乎每个同事都来问过我一轮。根因在于.gitignore只对未被跟踪的文件生效。如果一个文件已经被git add或git commit跟踪了之后再往.gitignore里写忽略规则是不管用的。对于已经误提交的文件正确的补救顺序是# 从Git跟踪中移除但保留本地文件 git rm --cached 具体文件名 # 如果要移除整个目录用 -r git rm -r --cached 某个目录/ # 然后把该路径写进.gitignore echo 具体文件名 .gitignore # 最后提交一次 git commit -m 停止跟踪无用文件从--cached这个参数也能再次体会到前文说的三个区域模型它只把文件从暂存区的索引中删掉本地工作区的文件还在。另外提醒一句配置生成目录、本地环境变量文件、IDE的.idea/或.vscode/这些都应该在项目一初始化就把规则写好靠后期补救容易漏。5.2 SSH认证失败从报错信息看known_hosts和多密钥冲突SSH方式连远程仓库报错通常有两种看得懂报错就能快速定位。第一种是提示host key verification failed同时给出REMOTE HOST IDENTIFICATION HAS CHANGED。这通常是目标服务器的SSH指纹变了系统做安全拦截。常见诱因是服务器重装过、换了认证方式或者你连错服务器了。处理方法是删掉known_hosts里的旧指纹ssh-keygen -R 服务器地址 # 然后重新连接按提示接受新指纹注意ssh-keygen -R是把特定服务器从known_hosts里删掉不是删整个文件这比直接清空known_hosts安全不至于把其他正常服务器的指纹一起清掉。第二种是权限认证失败提示Permission denied (publickey)。检查三件事公钥是否正确粘贴到代码平台本地有没有指定对的私钥如果你电脑上生成过多个密钥对是否给Git用错了账号的密钥。多密钥配置是很多人卡住的点。我电脑上同时有公司GitLab的密钥和Gitee的密钥如果只靠默认的id_rsaGit会一直用这把钥匙去连所有服务器连不上的那方就会认证失败。解决办法是编辑~/.ssh/config# 配置示例 Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa_gitee Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_rsa_company配置好之后Git会根据连的域名自动选择对应的私钥文件互不干扰。这个文件配置完立刻生效不需要重启什么。5.3 git目录泄露的防护与补救搜索引擎里git目录泄露如何下载这个词热度一直不低这提醒了我们一个反向问题如果自己部署的站点或服务器没有保护好.git目录别人可以通过特定路径直接下载Git历史等于把你的源码、密钥和内部文档全翻出来。这方面的安全意识值得从运维和部署层面补上。保护的核心就一条Web服务上不能让.git目录被直接访问。最稳妥的方案是部署时根本不把.git目录带到服务器上用CI/CD流程直接拉取打包好的产物而不是把整个源码目录扔上去。如果项目已经跑在Web上检查一下curl -I https://你的站点地址/.git/config如果返回200说明当前是泄露的需要立刻在Web服务器配置里拦截.git路径的访问。Nginx里这样加一段location ~ ^/\.git { deny all; return 404; }另外Git本身的仓库权限也要收好尤其是服务器上的裸仓库文件系统权限别开成777。已经泄露过的项目默认Git历史里所有早先提交过的内容都算泄露只修改当前代码并封住路径不够还得考虑对敏感历史做清理或直接重置仓库。这是个较低的配比成本但收益是真实的。6. 团队作战的高效命令stash、cherry-pick与差异比较6.1 stash手头改到一半被喊去修bug的标准解法你正在分支A上写功能写到一半文件都是散乱改动这时有人喊你切去分支B修个紧急bug。直接切分支会提示Working tree有改动妨碍切换硬要用git checkout -f切换会丢掉未保存的工作。正确的做法是暂存起来git stash push -m 功能A开发中 # 存入暂存栈 git stash list # 查看暂存列表 git stash pop # 恢复最近一次暂存并清除栈记录stash pop是恢复并移除记录git stash apply是恢复但保留记录适合需要同一次改动应用到多个分支的场景。暂存栈里东西多的时候用git stash apply stash{2}指定恢复某一项别用默认恢复把栈顶不需要的改动也拿回来。6.2 cherry-pick只想挑某个提交而不是整个分支有时候不想把整个分支合并过来只想把其中一个bugfix提交应用到当前分支这是cherry-pick的经典场景。比如修复线上bug的提交在main分支上hotfix分支只想拿这一个提交git cherry-pick 目标commit的哈希值执行完等价于把那个提交的改动应用到当前分支并生成一个新的提交记录。如果想一次性挑多个可以连续写哈希git cherry-pick A提交哈希 B提交哈希 C提交哈希如果挑来的提交和当前分支内容冲突处理方式和merge冲突一模一样解决完add之后git cherry-pick --continue。挑完发现不想要了git cherry-pick --abort能退出整个操作回到执行前的状态。6.3 对比与日志审代码前先学会看diff命令行的diff比图形界面更适合快速定位改动范围特别是配合过滤条件时效率很高git diff # 工作区 vs 暂存区未add的改动 git diff --cached # 暂存区 vs 版本库已add未commit的改动 git diff HEAD # 工作区 vs 版本库所有未提交改动 git diff 分支A 分支B # 对比两个分支的差异只看某个文件的改动在命令后加文件名git diff HEAD -- src/main/java/com/example/UserService.java日志查看方面大家都习惯git log --oneline但有几个参数很实用。-p能看到每个提交的具体代码改动--author按提交者过滤-S按代码内容搜索某个关键字的引入提交。找某段代码是谁在哪个提交里改出来的我通常用git log -S 被查找的关键词 --oneline这比手动翻历史高效太多。顺带一提git blame 文件名可以逐行查看每行代码的提交归属做代码归属排查的时候必用。写到这里Git命令行在日常工作中的核心场景基本都覆盖到了。回头看这十年用的工具Git是少有的底层机制理解越深、日常操作越简单的工具。最开始我也觉得命令难记但配合三区域模型去理解之后每条命令都会自然归位不再是一堆孤立的指令。如果只记住一条经验我会说尽量用命令行处理Git问题无论是在Idea里操作还是直接敲命令遇到搞不定的状态打开终端用git status和git reflog查看真实状态通常答案就在那两行输出里。下次你遇到git状态混乱别急着问AI先跑这两条命令很多问题自己就有眉目了。