Git日常操作实战：从环境配置到分支冲突解决完整指南

1. 环境准备与基础配置1.1 安装 Git 并完成首次全局配置不管你是刚入职的新人还是想把手头项目好好管起来的老手第一件事都是先把 Git 装好。很多人觉得这一步简单实际上装的时候有几个选项直接决定后面好不好用。先说 Windows 平台。去 git-scm.com 下载安装包一路 Next 的过程中有几个关键点要注意第一个是“Adjusting your PATH environment”一定要选第二项“Git from the command line and also from 3rd-party software”这样你在 CMD、PowerShell 里也能直接敲git命令不然装完只能在 Git Bash 里用习惯上总觉得隔了一层。第二个是默认编辑器强烈建议选 Visual Studio Code或者用几十秒钟学一下 Vim 的基本操作也行但别保留默认的 nanoCommit 提交信息时你会体会到差距。第三个是换行符转换方式新手阶段保持默认就好后面我会专门讲换行符那个坑。macOS 就简单多了。最省事的是装 Xcode Command Line Tools终端里执行xcode-select --install就会自动带上 Git平时写代码绝对够用。如果你想保持最新的 Git 版本再用 Homebrew 执行brew install git。Linux 系这边Ubuntu/Debian 用sudo apt install gitCentOS/RHEL 系用sudo yum install gitFedora 用sudo dnf install git都能很快搞定。装完先验证一下版本git --version然后必须做的一件事是配置用户名和邮箱。这一步不做你第一次 commit 的时候就会出现两种情况要么直接报错说缺少身份信息要么提交记录里显示的是一个系统自动生成的奇怪名字比如“userDESKTOP-XXXX”。公司的代码仓库里出现这种提交记录代码评审的时候会非常尴尬。git config --global user.name Zhang San git config --global user.email zhangsancompany.com--global表示全局生效针对你这台机器上的所有仓库。如果某个项目需要单独用不同身份进到那个项目目录后去掉--global再设置一次就只对当前仓库生效。比如你在公司用公司邮箱个人开源项目想用另一个邮箱就在对应目录里单独配。配完之后用git config --list检查一下能看到所有生效的配置项。还有个实用的小技巧如果公司和个人项目都在同一台机器上可以把user.name和user.email写进~/.gitconfig的includeIf条件里根据目录路径自动切换身份这个等配置熟练了再研究也不迟。1.2 SSH 密钥配置与远程仓库认证拉取和提交代码绕不开认证这关。现在大多数团队都用 SSH 方式连远程仓库原因是 HTTPS 方式每次 push 都可能要输入账号密码虽然后续密码管理器能缓存但公司内部频繁换密码、不同平台账号密码还不一样体验非常差。SSH 配好后完全免密而且更稳。生成密钥很简单一条命令ssh-keygen -t ed25519 -C zhangsancompany.com-C后面的注释建议写你的邮箱方便以后在网页后台识别是哪台机器的密钥。一路回车到底就行默认生成在~/.ssh/id_ed25519和~/.ssh/id_ed25519.pub。老机器如果不支持 ed25519 算法退而求其次用ssh-keygen -t rsa -b 4096。密钥生成后千万别弄混id_ed25519是私钥留在本机谁也不给id_ed25519.pub是公钥要配置到远程仓库平台。查看公钥内容cat ~/.ssh/id_ed25519.pub把输出的内容复制然后分平台添加。Gitee 上到“设置 - SSH 公钥”GitHub 上到“Settings - SSH and GPG keys - New SSH key”GitLab 上到“Preferences - SSH Keys”粘贴保存即可。配完测试一下通不通ssh -T gitgitee.com ssh -T gitgithub.com看到 “Hi xxx! Youve successfully authenticated” 之类的提示就说明通了这个 xxx 就是你账号的昵称。如果返回Permission denied (publickey)多半是公钥没配、配错了平台或者私钥权限不对。Linux/macOS 下私钥文件权限要求是 600可以执行chmod 600 ~/.ssh/id_ed25519修一下。这里有个很容易踩的坑如果你同时用 GitHub、GitLab、Gitee 好几个平台公钥要分别加。平台上配的是公钥但私钥是你本机的同一个对应关系是“一台机器 一个平台账号 一套密钥”同一把公钥加到多个平台没问题只要你能区分是哪个平台的验证结果就行。公司内网如果用的是私有化部署的 GitLab域名和官方 GitLab 不一样公钥加在那个内网地址的 SSH Keys 页面里。1.3 从 Gitee / GitHub 拉取项目到 IDEA / VSCode很多朋友装完 Git 之后的第一件事就是把远程仓库的项目拉到 IDE 里。这个动作本质上是git clone但 IDE 把它做成了图形化界面省得记命令。IDEA 里的流程很清晰。新版操作是 File - New - Project from Version Control粘贴仓库地址选好本地目录点 Clone 就行。如果你登录了 Gitee 或 GitHub 的账号还能直接在仓库列表里选不用手抄地址。克隆完成后 IDEA 会自动识别 Git 项目右下角弹出分支信息直接用。VSCode 用户更简单。打开“源代码管理”面板快捷键 CtrlShiftG点“克隆仓库”输入 URL选择本地保存目录自动打开。或者用命令面板CtrlShiftP输入Git: Clone也是一样的。不过我更推荐你把命令行方式也练熟因为 IDE 里的克隆操作本质上就是帮你执行了下面这条命令git clone gitgitee.com:zhangsan/project.git克隆完进入目录cd project用git branch -a看所有分支。这里有一个特别多人问的问题明明远端有十几个分支clone 下来之后git branch只看到 master/main 一个分支是不是漏了不是。clone 默认只把远端默认分支建立为本地分支其他分支只是下载了“远程引用”需要用git checkout基于远程分支创建本地分支这个我下一节详细说。实操中大家经常在 IDEA 里遇到的情况是“拉取失败”或“clone 超时”多半不是 Git 本身的问题而是仓库地址用了https://开头在密码输入那步卡住或者内网环境没走通。这时候优先把地址换成 SSH 格式重试我见过太多人卡在这里。2. 拉取代码从克隆到日常同步2.1 clone、fetch、pull 三者的区别与适用场景很多新手分不清clone、fetch、pull三个命令到底有什么区别但它们的应用场景完全不同。git clone是“从零开始拷贝整个仓库”服务端的提交历史、所有分支引用都会下载到本地虽然默认只 checkout 一个分支一般只在第一次拿到项目时用一次。git fetch则是“把远端的新提交下载到本地但不做任何合并”。它可以让你悄悄看看远端发生了什么变化。执行完git fetch之后远程跟踪分支比如origin/master会移动到最新位置但你当前工作区的代码纹丝不动。git pull是“fetch merge”的组合拳把远端更新直接合并到当前分支。日常同步代码时最常用但正因为它是自动合并也最容易在不经意间制造冲突。一句话总结差异git clone # 首次拿项目 git fetch # 看一眼远端有什么不改变工作区 git pull # 拉取远端更新并立即合并到当前分支我个人的习惯是每天开工第一件事先git fetch看看有没有同事推了新东西确认之后再决定是git merge还是git rebase而不是无脑git pull。尤其在一个多人频繁改动的仓库里pull的自动合并有时会打乱你手头还没提交的代码提前看一眼总归更稳。2.2 分支查看、切换与基于远程分支创建本地分支分支是 Git 日常操作里绕不开的主题。刚 clone 完项目先摸清楚有哪些分支git branch # 只看本地分支 git branch -a # 看本地和远程所有分支 git branch -vv # 看本地分支和远端跟踪关联关系输出里带*的是当前所在分支名字是remotes/origin/xxx的表示远端分支。如果需要基于远端分支新建一个本地分支git checkout -b feature/login origin/feature/login这条命令的意思是基于origin/feature/login创建本地分支feature/login并切换过去同时自动建立跟踪关系。以后在这个分支上直接git pull/git pushGit 就知道该跟哪个远端分支交互不用每次补全参数。新版的 Git 还提供了语义更清晰的git switch系列命令git switch -c feature/login # 创建并切换 git switch feature/login # 切换已有分支如果本地没有同名分支直接git checkout feature/login也能自动基于origin/feature/login创建并跟踪但前提是远端确实存在这个分支。所以我更建议显式写清楚。切换分支前有一个非常关键的动作确认工作区干净或者把改动暂存起来。比如你正在改service层的代码突然要切到另一个分支修紧急 bug直接git checkout切过去的话那些未提交的改动会跟着你一起带到新分支。如果两个分支代码差异很大轻则出现一堆冲突提示重则把没写完的代码混进提交流程。正确姿势是先用git stash暂存切完分支修完 bug 再切回来git stash pop这个技巧在 4.3 小节会详细说。2.3 拉取冲突的成因与处理思路“拉取冲突”这个词听着吓人本质上就是你和别人改了同一处代码Git 自动合并时拿不定主意只能请你来裁决。场景重现你和同事都在改UserService.java他先提交并推送了你后执行git pull。Git 在合并远端更新时发现同一行你俩都改了无法判断该保留谁的于是抛出冲突Auto-merging src/main/java/UserService.java CONFLICT (content): Merge conflict in src/main/java/UserService.java这时候打开冲突文件你会看到一堆标记 HEAD 你的代码 同事的代码 origin/master其实很好理解HEAD是你当前分支的内容下面是拉取进来的远端内容。解决方式就是手工决定保留哪一边、或者两边都保留然后删掉这些标记行。具体步骤大概是git status找到所有冲突文件状态显示为both modified。逐个打开文件处理冲突标记。处理完git add这个文件。git commit完成这次的合并提交。我的经验是小文件的冲突手工改很快但大文件、多文件冲突一定要用 IDE 的可视化合并工具。IDEA 的 Resolve Conflicts 面板能左右对照VSCode 里也有 Accept Current Change / Accept Incoming Change / Accept Both 这几个按钮比纯文本编辑器盯着发呆靠谱得多。更聪明的做法是减少冲突发生。功能尽量拆小、提交尽量频繁涉及公共接口或公共类的时候先在群里喊一声“我要改这边了”都能大幅降低冲突概率。冲突本身不是 Git 在找麻烦反而是它在保护你的历史不被打乱。2.4 高频拉取实战新环境从零拉下一个项目把前面这些串起来走一遍“从零开始在一个新环境下拿到项目”的完整流程感受一下真正的日常。假设公司项目在 GitLab地址是gitgitlab.example.com:team/project.git第一次在新电脑上操作先确认 SSH 通道正常。这一步经常被省略然后 clone 失败时才开始怀疑人生。ssh -T gitgitlab.example.com通了之后直接克隆git clone gitgitlab.example.com:team/project.git cd project看分支情况git branch -a假设前端团队一直在dev分支上开发你想跟到dev上去git checkout -b dev origin/dev这时候本地dev分支和远端origin/dev已经建立了跟踪关系。之后每天开始工作前执行一次git pull origin dev就能把同事的最新改动拉下来合并到本地。这里有个很典型的提交顺序问题你在本地dev上改了半天代码想推上去结果git push origin dev报错non-fast-forward。原因是远端已经被别人推了新提交你的本地历史落后了。解决方式有两种一种是无脑git pull再 push生成了一个合并提交另一种是git pull --rebase把你的提交“垫”到远端最新提交后面历史更干净。我个人倾向后者后面 3.2 小节会对比这两种方式。还有人会问我本地master已经落后远端很多了直接拉取行不行行git pull origin master就行但如果本地master上有你自己没推过的提交一样会有合并操作。总之记住pull是“同步 合并”不要指望它只做同步。3. 提交代码从工作区到远程仓库3.1 工作区、暂存区、版本库先搞懂这三块地儿很多人提交代码全靠背命令加了一个文件到底发生了什么完全没概念。我建议先花五分钟理解 Git 的三个存储区域之后遇到任何奇怪问题都不慌了。工作区Working Directory你看着的、正在编辑的文件就是磁盘上的真实文件。暂存区Index / Staging Area执行git add之后文件进入的状态相当于一个“待提交清单”。版本库Repository / .git执行git commit之后改动真正写入 Git 的数据库成为历史的一部分。打个比方你要寄一批快递先从书桌上挑选要寄的东西放进纸箱add封好箱子交给快递员commit快递发出去了push。书桌是工作区纸箱是暂存区快递公司是版本库。这个模型能帮你解释很多现象为什么git add之后改动还没提交git status显示的是Changes to be committed为什么git commit之后工作区还有内容但git status已经“干净了”。本质上它们都是文件在不同区域之间的搬运。理解区域之后另外两个命令也好懂多了git diff # 工作区和暂存区的差异你改了啥还没 add git diff --staged # 暂存区和版本库的差异你 add 了啥还没 commit你刚修改还没 add 的内容只有git diff能看到add 之后再看就要加--staged参数了。哪个区域在哪一步永远先git status看一眼再决定用什么命令。3.2 标准提交流程add、commit、push 的每一步提交代码的标准动作不算多但每一步都有讲究。# 第一步看看当前状态 git status # 第二步把想提交的文件加入暂存区 git add src/main/java/com/example/UserService.java # 第三步再确认一次暂存内容 git status # 第四步提交到本地版本库 git commit -m feat: 增加用户查询接口 # 第五步推送到远端 git push origin dev第一处容易出问题的是git add的粒度。强烈建议逐个文件add而不是一上来就是git add .。一次只提交相关的改动提交历史才清晰回滚才能精准找到目标。如果你只是临时改了个调试日志却和正式功能混在同一个提交里以后排查问题会非常痛苦。第二处是push前要不要先pull。如果远端已经有人推了新提交你直接push会被拒绝提示non-fast-forward。这时候需要先把本地同步到最新。两种常见方式方式一git pull origin dev git push origin dev方式二git pull origin dev --rebase git push origin dev方式一会在本地产生一个“合并提交”merge commit历史变成分叉再合并的形状方式二会把你的提交重新放到远端最新提交之后历史是一条直线。共享分支上我一般建议方式一因为合并提交记录了“同步这个动作”本身多人协作时更好追踪个人功能分支上想保持历史整洁用方式二更合适。不要每次遇到pull就无脑点 IDE 里的拉取按钮搞清楚自己在哪种场景心里才有底。第三处是commit信息。git commit -m xxx只能写一行信息稍微长一点就不够用。更规范的方式是不加-m让 Git 打开编辑器写多行git commit第一行写简明摘要空一行然后详细描述改动原因、影响范围。这让以后翻git log的人包括未来的你自己能快速理解当时为什么这么改。3.3 提交信息怎么写从“能看懂”到“能追溯”提交信息这事儿很多团队没意识到它的重要性。你一个星期前提交的代码一个星期后你同事要 review 时只会看到一句update那不是提交信息那是给别人添堵。比较通用的一套规范是 Conventional Commits约定式提交格式是type(scope): subjecttype表示类型常用的有feat新功能fix修复 bugdocs文档变更style格式调整不影响逻辑refactor重构不改功能perf性能优化test测试代码chore构建/工具链等杂项scope是影响范围比如模块名subject是简要描述。看几个例子feat(user): 增加用户登录接口 fix(order): 修复订单超时未关闭的问题 docs(readme): 更新部署说明 refactor(cart): 拆分购物车计算逻辑这样写的好处太多了。git log --oneline一眼扫过整个项目的历史脉络清清楚楚代码评审时 MR 的标题直接复用提交信息甚至可以用脚本自动生成 CHANGELOG。我强烈建议团队把这种格式定为硬性规范Code Review 时看到fix bug之类的信息一律打回重写。中文还是英文倒是次要的团队统一就行。但格式规范和描述颗粒度必须统一这是“提交信息能从能看懂变成能追溯”的关键。3.4 权限边界Developer 角色为什么不能直接推 master有一类热搜问题特别典型“GitLab 里 Developer 角色可以提交代码到 master 吗”答案是通常不行。现在的代码托管平台基本都默认保护主干分支。GitLab 的 master/main 默认是 protected branchGitHub 的主分支也默认 protected。开发者Developer角色的权限是可以 clone、pull、在非保护分支上 push但不能直接 push 到受保护分支。那日常流程是什么以 GitLab 为例从master拉出一个功能分支比如feature/login在上面开发提交。推到远端git push origin feature/login。在 GitLab 网页上发起 Merge Request把feature/login合入master。评审人 Review 代码通过后由有合并权限的成员或者自动化流程合并。GitHub 对应的概念叫 Pull Request流程大同小异。这不是平台故意设卡而是工程管理的基本盘保护主干稳定进主干的每一份代码都经过 Review出问题知道找谁CI 也能在合并前跑一遍检查。所以如果你发现git push origin master被拒提示You are not allowed to push code to protected branches on this project别慌不是你 Git 坏了是你的权限模型限制了行为方式按 MR 流程走才对。刚入职的开发者尤其容易在这件事上困惑以为被拒是配置问题到处找运维改权限。实际上正确动作是问清楚团队用的是 MR 流程还是一直用主干开发流程trunk-based。大多数正规团队都会让你走 MR。3.5 强推force push的适用场景与翻车风险git push --force简写-f是个高危动作但也是不得不学的技能因为有些场景绕不开。先说命令本身的语义它强制让远端分支指向你本地分支的位置不管中间是否有分歧。适用场景你重写了本地提交历史比如用了git rebase整理 commitpush 时因为历史不一致被拒需要强推才能让远端跟着走。你刚推送了一个包含敏感信息的错误提交紧急回滚后需要强制覆盖远端。个人功能分支发展过程中你想把几个琐碎 commit 合并成一个大 commit再更新到远端。翻车场景就多了。最常见的是一个分支是你和同事共用的你rebase之后强推上去同事本地还停留在旧历史下次pull直接炸出一堆冲突甚至历史错乱。更严重的是对 master/main 强推等于把团队辛苦积累的提交抹掉一批。如果你必须在共享分支或已有他人提交的分支上做调整建议使用更安全的变体git push --force-with-lease这条命令的逻辑是只在我确认远端还停留在我上次看到的那个位置时才强推。如果别人已经推了新提交--force-with-lease会拒绝操作避免把你不知晓的提交覆盖掉。简单说-f是莽夫--force-with-lease是带着检查的莽夫。我的原则是推送到主干或共享分支永远不碰force。个人分支上想整理历史优先用--force-with-lease。消息里提示你要强推的时候先停三秒想想这个分支上有没别人的东西。4. 高频命令速查手册场景导向4.1 日常开发最常用的 20 个命令这一节把日常场景里用到频率最高的命令整理成一张速查表每条附一句使用场景。不需要死记硬背遇到问题翻一翻用几次就记住了。命令作用示例 / 说明git clone url从远程仓库克隆项目git clone gitgitee.com:user/project.gitgit status查看工作区与暂存区状态显示 modified、staged、untrackedgit add file把文件加入暂存区git add src/main/java/UserService.javagit commit -m msg提交暂存区到本地版本库git commit -m fix: 修复登录超时git push remote branch推送本地提交到远端分支git push origin devgit pull remote branch拉取远端更新合并到当前分支git pull origin mastergit fetch下载远端更新但不合并git fetch origingit branch查看/创建/删除分支git branch -agit checkout branch切换分支git checkout devgit switch -c branch创建并切换分支git switch -c feature/logingit merge branch合并指定分支到当前分支git merge feature/logingit rebase branch把当前分支提交重放到目标分支上git rebase mastergit stash暂存未提交的改动git stash save 临时保存git stash pop恢复最近一次 stashgit stash popgit log --oneline简洁查看提交历史git log --oneline -5git diff查看未暂存的改动git diff src/main/java/UserService.javagit diff --staged查看已暂存改动git diff --stagedgit reset回退本地提交常用--soft/--mixed/--hardgit revert HEAD撤销最近一次提交生成反提交git revert HEADgit remote -v查看远程仓库地址常用于确认连的是哪个源这张表基本覆盖了一个开发者一天 80% 的 Git 操作。想再进阶一点可以加上git tag打标签、git show查看某次提交详情、git blame定位某行代码的修改人、git cherry-pick把单个提交挑选到当前分支这几个。4.2 分支合并与冲突解决实战合并分支是 Git 使用中绕不开的环节。假设你在feature/login分支上开发完了要合入到mastergit checkout master git pull origin master # 让本地 master 保持最新 git merge feature/login # 把功能分支合进来 git push origin mastermerge的特点是保留两个分支各自的提交历史并生成一个合并提交能看出“从哪合到哪”。适合团队协作因为历史更真实。另一种合并思路是rebasegit checkout feature/login git rebase master它会把你的本地提交逐个重放到master最新提交的后面最终历史是一条直线。好处是清晰坏处是你本地的提交哈希被重写了如果这些提交已经推到远端就需要强推风险随之而来。什么时候选哪个我的经验是功能分支合并回主干用merge保留完整开发脉络个人功能分支想保持线性历史、想和主干保持同步用rebase。不要在共享分支上随意rebase并强推前面已经强调过这是事故高发点。合并过程中遇到冲突不需要慌。冲突文件的状态是both modified每一处冲突都有标记。处理完冲突merge场景下执行git add然后git commitrebase场景下执行git add然后git rebase --continueGit 会继续重放后面的提交。如果不想要这次合并了git merge --abort或git rebase --abort都能撤销。我处理冲突的固定流程先git status摸清冲突文件名单再打开文件逐个解决解决完先用git grep -n 全项目搜一遍冲突标记确认没有遗漏才add和commit。别小看最后这一步搜索我见过太多人漏删标记提交上去接着报错反而更浪费时间。4.3 临时切换任务stash 暂存操作想象这个场景你正在feature/login分支上写登录逻辑写到一半还没提交突然线上有个紧急 bug 需要你去master分支马上修。这时候工作区一堆半成品代码硬切分支不仅会把改动带过去还可能在master上编译都不通过。git stash就是为这种场景准备的。它把当前所有未提交的改动保存到栈里让你的工作区回到干净状态git stash save 登录页功能开发中然后放心切分支git checkout master修完 bug提交推远端切回来git checkout feature/login git stash pop改动原封不动回来了。几个变体记住就够用git stash list # 查看所有 stash 记录 git stash apply # 恢复某次 stash 但不删除记录 git stash drop # 删除某条 stash 记录 git stash pop # 恢复最近一次 stash 并删除该记录 git stash -u # 连同未跟踪的新文件一起暂存几个容易踩的坑默认的git stash不包含新建而未跟踪的文件想一起存上要加-ugit stash pop时如果当前工作区正好也有改动可能冲突冲突解决方式和普通冲突一样。如果 stash 里的改动被其他分支先恢复过再 pop 时会提示没有可恢复的内容用git stash list能看到实际状态。这种切换任务的操作很日常练熟了能减少大量“代码带到错误分支”的麻烦。我建议每次切分支前都默念一句工作区干净吗不干净就 stash。4.4 回滚与后悔药reset / revert / checkout代码写错了想回到之前某个状态是 Git 用户问得最多的问题之一。Git 提供了好几种“回滚”方式关键在选对场合。最安全的是文件级的还原用git restore老版命令是git checkout -- 文件git restore src/main/java/UserService.java它的作用是丢弃该文件在工作区的未提交改动恢复到暂存区或 HEAD 的状态。注意这个操作不可逆改了半天没提交的内容都会消失。如果你想撤销的是“提交”就需要分清reset和revert。git reset移动本地分支的 HEAD 指针有三种模式git reset --soft HEAD~1 # 撤销提交但保留暂存区和工作区改动 git reset --mixed HEAD~1 # 默认模式撤销提交和暂存区保留工作区改动 git reset --hard HEAD~1 # 彻底撤销提交工作区也回到之前状态--hard最危险但用起来最直观回退之后该删的文件、该还原的改动全都没了。只建议在本地提交且明确知道自己在干什么的时候用。git revert则是生成一个新的“反提交”来抵消指定的提交历史永远是向前走的git revert HEAD这条命令会新建一个提交把最近一次提交的改动倒回去。它的最大好处是安全因为历史没被改写推到远端也不会影响别人特别适合已经推送过的提交。选哪个的准则就一条这个提交推没推过远端。没推过可以用reset随便折腾推过了默认用revert别碰reset 强推。在主干上强推回滚几乎是工程事故后果相当难看。4.5 忽略文件与 .gitignore 实战每个项目里都有一类文件不该进版本库比如node_modules、target、.idea、*.log、.env。这时候就需要.gitignore文件。它告诉 Git 哪些文件或目录不要跟踪。以 Java 项目为例一份常见的.gitignore长这样target/ *.class *.log .idea/ *.iml .vscode/ .env语法不复杂记住几个要点/target表示忽略target目录。*.log表示忽略所有以.log结尾的文件。!important.log表示取反不忽略important.log。末尾带/说明是目录比如build/。生成模板可以从 toptal.com/developers/gitignore 按项目类型挑也可以 gitignore.io 自定义组合省得自己慢慢写。用.gitignore有个高频困惑我明明加了规则为什么文件还是被跟踪这是因为 Git 对“已经被跟踪的文件”不会自动应用忽略规则。你必须在规则生效前先把它从版本库里移掉但保留本地文件git rm --cached config/local.properties--cached参数是关键它只移除版本库中的跟踪信息不删除你磁盘上的文件。处理完一批文件后提交一次之后的改动才会遵循.gitignore。顺带一提.gitignore文件本身一定要提交到仓库里团队成员才能共享同一套忽略规则不然你随手生成了.idea配置、他提交了node_modules仓库越来越臃肿问题还不好排查。5. 常见问题与排查技巧实录5.1 认证失败用户名密码与 SSH 的问题认证失败是 Git 日常操作里出现频率最高的问题之一。典型报错remote: HTTP Basic: Access denied fatal: Authentication failed for https://...这种大多出现在 HTTPS 方式下。排查思路从简单到复杂一层层来确认账号密码是不是最新。很多平台的密码策略会要求定期改密码或者说本地记住了旧密码。GitHub 早已不支持用密码直接 push需要 Personal Access TokenPAT在 GitHub Settings 里生成一个把 token 当密码填。检查 URL 里有没有带旧用户名https://usernamegithub.com/xxx/xxx.git这种带username的写法如果username过期或输错了直接失败。清掉系统里缓存的旧凭据。Windows 上到“控制面板 - 凭据管理器 - Windows 凭据”把和 git 相关的条目删掉再试。SSH 方向也常见两类问题。Permission denied (publickey)说明公钥没配对或者私钥没加载先ssh -T gitgitee.com测通道。如果还没配过密钥回到 1.2 小节把流程走一遍。另一类是Host key verification failed多发生在首次连接一个未知 Host安全起见确实应该确认指纹后再继续别直接跳过。同时用多个 SSH key 的管理建议在~/.ssh/config里按域名区分Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519 Host github.com HostName github.com User git IdentityFile ~/.ssh/github_key这样不同平台自动选用不同私钥不会出现“GitHub 认了Gitee 不认”的情况。5.2 拉取失败网络、仓库源、权限的排查思路“拉取失败”这个概念太宽泛了但排查框架其实很固定。先瞄准现象再一层层剥。第一层网络通不通。浏览器能不能打开仓库页面能打开说明网络没问题继续往下走打不开先解决最基本的连通性。第二层端口通不通。SSH 默认走 22 端口很多公司网络出口限制严格21/22 这种端口直接被掐。HTTPS 走 443一般更宽松。所以克隆或拉取时如果走 SSH 超时可以试试把地址换成 HTTPS 形式反过来也一样。第三层仓库源本身对不对。地址拼写有没有错git开头还是https://开头仓库改成私有后原地址是否还有效经常能看到有人拿旧地址拉取返回 404 还莫名其妙。第四层权限够不够。私有仓库要求账号有权限GitHub/GitLab/Gitee 上如果git clone返回 404有一部分原因是“这个账号看不到这个仓库”。401 则是认证失败账号密码或 token 的问题。403 一般是指没有操作权限比如没有 push 权限。第五层本地环境问题。磁盘满了、目标目录没有写入权限、文件被占用也会导致拉取/克隆失败。先df -h看看磁盘ls -ld看看目录权限。说句题外话这种“拉取外部资源失败”的排查思路不只对 Git 有效。网上经常有人问 Docker 拉取镜像失败、部署服务时从镜像仓库拉取组件失败、甚至业务系统从数据服务器拉取文件失败核心排查顺序都差不多先分清是源的问题还是网络的问题再判断是认证问题还是本地环境问题一层层缩小范围别一上来就怀疑代码写错了。Git 只是这个方法论里最常见的一种场景。5.3 冲突解决实战一次次 Git 冲突后的经验沉淀冲突解决这事儿理论上前面已经讲透了但把真实经历写下来还是有很多值得分享的体会。有一次我同事改了一个 Service 接口往里面加了参数我同一天在那个接口的调用方加了个新的判断逻辑。他先推我后pull冲突直接落在方法签名那一行。当时我想着快点搞定直接选了“保留我的版本”然后git add .提交推上去。第二天同事跑过来说调用方的方法和 Service 签名对不上了编译不过。我这才意识到冲突解决不是“选 A 还是选 B”这么简单而是要理解两侧的意图把代码融合成“既包含对方改动也包含我改动”的版本。后来我给自己立了几条规矩冲突文件逐个看不全部盲选“Accept Both”。有些冲突看起来两边都能留但实际上逻辑重复了留着就是技术债。涉及公共接口或类名变更的冲突解决完一定跑一遍全量编译或者相关测试。语法正确不代表逻辑正确接口签名对不上在编译期就能发现别等到部署。合并前先用git fetch看看远端提交信息心里有数。如果同事刚改了某个类我能提前知道合并时更有针对性。大文件冲突优先用 IDE 的合并工具效率高得多。VSCode 和 IDEA 的冲突界面都能清晰展示 base / local / remote 三栏。还有个小技巧解决完冲突后搜索一下整个项目里还有没有残留的冲突标记git grep 这个命令在修改列表里执行能找出所有还没有解决的冲突位置。我曾经因为漏了一个标记提交上去后 IDE 提示语法错误白白多花了一个小时这种教训一次就够了。5.4 其他高频小毛病换行符警告、中文乱码、文件大小写等Git 日常操作里的“小毛病”看起来不起眼但处理不好也让人抓狂。第一个是换行符警告。Windows 用户提交代码时经常看到warning: LF will be replaced by CRLF原因很简单Windows 用CRLF结尾Linux/macOS 用LF结尾Git 默认在检出/提交时自动转换于是发出了提示。这个提示本身无害但要防止团队内“同一个文件一会儿 LF 一会儿 CRLF”造成无意义的 diff。比较好的方式是仓库根目录放一个.gitattributes文件声明统一规则* textauto *.sh text eollf *.bat text eolcrlf比让大家各自配置core.autocrlf在团队里更容易统一。第二个是中文乱码。Windows 上 Git 日志里中文提交信息、中文文件名显示成转义符\345\274\240很让人头大。执行git config --global core.quotepath false中文路径就能正常显示了这个配置我每次新装 Git 都会顺手配上。第三个是文件名大小写问题。把README.md改成readme.mdmacOS 和 Windows 的文件系统默认大小写不敏感Git 可能认为文件没变化远端还是旧名字。正确做法是用git mv明确告诉 Git 要改名git mv README.md readme.md第四个是在公司内网拉取代码偶尔出现连接被重置或者超时。这种一般是网络出口限制可以优先试试切换协议SSH 换 HTTPS或者 HTTPS 换 SSH或者询问运维是否有内网专用的仓库地址。还有人会顺手配置一个内部网络通道来解决但这类操作遇到特殊网络环境时建议直接找 IT/运维确认别自己在本地乱试。最后的几点心里话这篇文章里大部分命令都是我被 Git 虐过很多次之后真正沉淀下来的。刚开始的时候我也只会三次板斧add、commit、push遇到冲突就慌遇到强推报错就愣住直到有一次不小心把同事的提交历史搞乱了才意识到 Git 这东西“会用”和“用得明白”是两回事。最后分享一个我保持了很多年的习惯每天开工第一件事先git fetch看一眼远端有什么变化下班前git status确认自己的改动都有明确的下一步。这两个动作从来不会错也能让你第二天早上回来时心里有数。Git 本身不复杂复杂的是搞不清自己离提交、离推送、离冲突还有多远。把这套日常操作的流程吃透不管在哪个团队、哪个平台你都能很快进入状态。