1. 哪些文件该交给Git管哪些不该聊Git具体操作之前先把一个认知问题掰扯清楚Git不是用来管“所有文件”的它只负责管那些“需要追踪变更”的文件。很多人刚入坑时习惯git add .一把梭结果把依赖、密钥、构建产物全提进仓库之后每次拉取都痛不欲生。按我自己的经验适合交给Git管理的文件大致分三类源代码文件.py、.js、.java、.go、.vue、.c这一类Git最基本的职责就是追踪它们的每一次增删改。配置类模板比如.env.example、nginx.conf.example、docker-compose.yml注意是模板而不是真实配置。真实配置往往带密钥和机器专属路径不应该进版本库。文档与脚本README.md、docs/目录、部署脚本.sh、数据迁移脚本等这些为团队沉淀知识配合Git的diff能力再好不过。反过来下面这几种文件我强烈建议你挡在Git门外node_modules/、vendor/、target/、dist/这类依赖和构建产物它们可以被锁文件或构建脚本一键生成.env、config/local.yml、*.pem、*.key这类带敏感信息的文件一旦提交就可能造成凭据泄露本地IDE配置里属于个人习惯的部分比如.idea/workspace.xml、.vscode/下某些只对你生效的配置日志文件与大体积资源*.log、超过几十MB的二进制包这些命中Git无法高效处理的痛点。一句话总结Git管理的是“源”和“模板”而不是“结果”和“秘密”。先把这两类分清楚后面的所有命令才用得安心。2. 零基础到跑通第一笔提交完整动手流程还没装Git的话先去官网下载对应系统的安装包。安装过程基本不用改选项只有一步注意一下安装Git Bash时保留默认勾选即可这是Windows下非常好用的命令行环境后续所有操作都用它避开CMD的坑。装完在终端敲git --version能输出版本号就说明装好了。要是连版本都输不出来大概率是环境变量没配上走系统环境变量把Git的cmd目录加进去就行。2.1 先配置身份不配用户名和邮箱没法提交第一次用Git的人往往会卡在这样一个报错上Please tell me who you are.这是因为Git在提交记录里要写着作者是谁。给机器和人一样代码仓库也要知道“谁在干活”。配置方式git config --global user.name 你的昵称 git config --global user.email 你example.com--global表示全局生效作用于这台机器上所有仓库。如果某个项目想用另一个身份只要在仓库目录里去掉--global重新配一次即可作用域更小的配置会覆盖全局配置。2.2 从零建仓库让Git开始观察这个文件夹mkdir my-project cd my-project git init执行完git init后文件夹里会出现一个隐藏的.git目录Git从这个瞬间开始跟踪所有被add过的文件的变动。此时库里还没有任何提交记录。接着创建几个文件并建立首个提交echo # 我的第一个项目 README.md git add README.md git commit -m 初始化项目添加READMEgit add先文件加入暂存区git commit再生成一条不可变的快照记录。这个顺序就是Git最核心的工作流修改 - 暂存 - 提交。2.3 修改文件并看差异Git到底在帮你记录什么继续加一个.gitignore文件放上丢给Git忽略的东西node_modules/ dist/ *.log .env保存后用git status能看到它是未跟踪状态之后执行git add .gitignore再git commit -m 添加忽略规则完成提交。此时再把README改一行echo 更详细的说明 README.md git diffgit diff输出的是工作区相对暂存区的差异。看完几处改动你觉得没问题还是老一套git add再git commit。这就是正常工作状态下的循环真正把这个循环养成肌肉记忆后续的高级操作自然就顺了。3. 版本回退的保命操作后悔药这样吃写代码不可能不犯错版本回退就是干这个用的。它解决的问题是做了一堆改动后发现全错了或者在分叉的某次提交里留下了Bug我想跳回到之前某个稳定状态。3.1 先用 log 看清历史任何回退操作之前先搞清楚自己在哪里、有哪些历史提交git log --oneline --graph --all--oneline让每次提交只显示一行--graph用字符画出分支图--all把远程和本地分支的历史都展示出来。执行后你会看到类似这样的信息* 3b5f1c9 (HEAD - main) 修复登录态问题 * 9e7a2d1 完成用户模块模板 * 4d1c0aa 初始化项目这里每一行开头那一串字母数字就是commit哈希它是这次提交的身份证号。想回退到4d1c0aa那这就是你的目标点。3.2 reset 的三个档位git reset按影响范围分成三档别用错第一档--soft只移动HEAD指针工作区与暂存区都不动改完之后所有差异全部停留在暂存区。git reset --soft 4d1c0aa执行完git status一看后面两次提交的改动全在绿色暂存区里等着。这个档位的用途是合并提交记录连续提交了好几次发现“这几笔可以合成一笔”回退后重新git commit即可。第二档--mixed默认行为移动HEAD并清空暂存区但工作区文件内容保持不变。git reset 4d1c0aa此时后面提交的改动会以“未暂存”状态出现在工作区需要重新git add再提交。第三档--hard全量回退工作区文件内容也一起变回目标提交。git reset --hard 4d1c0aa这一档最省心也最危险连同工作区里的修改一并丢弃。执行前确认没有留下任何有价值的未提交内容。3.3 回退错了也有后悔药被reset抹掉的提交不会彻底消失。Git的引用日志reflog会记录HEAD的每一次移动哪怕那次移动把提交“删掉了”。git reflog输出里能看到每次HEAD、分支等引用的变动历史包括被reset丢弃的那个提交哈希。想找回时直接git reset --hard 这个哈希值所以秘诀是对当前仓库状态不确定、怕搞坏的时候先看一眼git reflog再决定要不要下手。我自己的习惯是每次reset --hard之前都会先记下当前哈希给自己留个“再反悔一次”的机会。3.4 reset 和 revert 到底该用哪个reset会改写历史适合在代码还没推送到远端时使用一旦提交已经被其他人拉取或者被推送到公共分支再用reset就相当于对别人说“我改写了历史请重新同步”很容易引发混乱。这种情况的正解是revert它不动原提交而是生成一种“反向提交”把改动抵消掉。git revert 3b5f1c9执行后会新增一条提交内容是把3b5f1c9本次提交引入的差异全部撤销。这也意味着历史里能保留那条原始提交溯源性更好。所以判断标准很简单本地未推送用reset公共分支用revert。4. 撤销各种状态的修改从工作区到暂存区到远端撤销修改最常见的场景我分了四类每一类有不同的套路选择错误会导致改动没能按预期恢复。场景一工作区改坏了但还没add比如我把README.md改成乱码又不想保留。这时候直接git restore README.md这个命令会用暂存区或HEAD里的内容覆盖工作区。它只会动这个指定文件其他文件不会受到牵连执行后那些未暂存的改动就消失了。场景二已经add进暂存区想反悔git restore --staged README.md--staged参数表示把暂存区的添加动作取消让文件回到未暂存状态。注意这里只是取消暂存文件内容改动依然保留在工作区里。场景三提交记录里面出了错想改掉但又不想新增一条提交这种情况用commit --amend。假设我提交信息写错了可以git commit --amend -m 修正后的提交信息或者忘记加某个文件也可以重新add之后再amend把新改动并入上一个提交。务必注意它实际上是在替换最后一次提交如果这个“最后一次提交”已经被推送到公共分支请改用上面讲过的revert。场景四错误提交已经推送到远端这个没有“一键撤回”最稳妥的路线是组合拳git revert 出问题的哈希 git push origin main先用revert制作反向提交再推送这个反向提交到远端。这条新旧提交并存的方案是全团队都能接受的回退方式其他人同步时不会遇到历史被改写的冲突。这四类场景分别对应同一套底层逻辑修改到底停留在哪一层就从哪一层下手恢复。区分清楚工作区、暂存区、本地仓库、远程仓库这四个概念绕开80%的撤销事故。5. 删除文件从版本库中出局的正确方法删除是版本管理里最容易被误解的动作。很多人直接用系统删除工具或者rm删文件以为自己已经“删除干净了”结果一看git status发现Git还在那跟踪着它。5.1 用 git rm 而非系统 rm命令行环境里正确做法git rm README.md这句命令等价于先系统删除文件再执行git add把删除动作放入暂存区。这样一次操作就把“删除”这个事实告诉了Git再git commit -m 删除README.md即可让改动正式生效。想删除一整个目录git rm -r docs/-r表示递归删除docs目录下的所有文件。5.2 误删之后怎么找回分了两种误删已提交的场景用restore恢复git restore README.md因为Git仓库中还有这个文件的提交历史restore会从HEAD把它重新捡回工作区。未提交的场景需要查看版本库内是否留有这个文件的提交如果从未提交过且未跟踪那么删除后就无法找回了。所以日常写代码时任何有价值的文件创建后都应尽快进入版本库。5.3 只想让文件不再被跟踪但保留本地这种情况常见于使用.env之前文件已经提交进了仓库之后想改成“不入库”的状态。方法git rm --cached .env--cached意思是只把文件从暂存区也就是版本跟踪范围里移除本地磁盘文件不动。执行后记得把这个文件名加入.gitignore避免再次误add。然后提交这条删除远程仓库里的对应文件也会消失。5.4 清理凭据文件时务必确认两遍我因为在演示项目里提交过真实密钥文件吃了不少亏现在养成的习惯是删除任何含密钥、cookie、私有token的文件之前都先git log --all --oneline -- 文件名查一遍该文件是否曾出现在历史提交中。如果出现过单纯删除当前版本即可但历史提交里仍然保留着旧内容此时需要配合git filter-repo或改写历史来彻底清理。这一步跟删除文件本身是两个层级的问题版本库里的内容一旦提交过就永久存在于历史中删除只影响后续记录不影响过去。涉及真实生产密钥的场景需要一个不漏地把历史一并清理干净。6. 一个仓库的完整日常操作刷卡轮回把前面各节的操作串成一个完整的日常循环这就是每个接触Git的人每天都要走的流程。早上到岗后先拉取最新代码git pull origin main注意origin是Github/Gitee等远端仓库的默认别名main是需要同步的分支名。拉完自己新建功能分支去开发git checkout -b feature-login这条命令创建一个新分支并切换过去。在这个分支上做若干次修改中间多次走edit → git add → git commit小循环。全部完成并测试后合并回主分支git checkout main git merge feature-login如果合出冲突git status会标出冲突文件手动处理后重新git add再git commit即可。最后推送git push origin main这套动作熟练之后可以在1分钟内完成“拉取-开发-提交-推送”的全部环节。最大的好处是每次改动都有迹可查哪个提交改了什么什么时候改的为什么这么改全都有信息可追诉。很多初学者在折腾merge后误以为分支是一种很复杂的架构其实分支只是一条提交时间线上的游标工具。理解了这一点常用的git checkout、git merge、git rebase这些操作就不再像黑魔法而是一次干净的普通切换。7. 配置远程仓库并学会推送代码自己本地练熟了之后很快就遇到“想让代码备份到云端”或者“和同事协作”的需求。这就要用到远程仓库。第一步在代码托管平台建一个空的远端仓库通常选择“创建新仓库(New Repository)”。创建时不要勾选生成README避免与本地仓库历史产生分叉。第二步本地关联远端git remote add origin gitgitee.com:你的用户名/my-project.git这里的地址是SSH形式更常见的还有HTTPS形式例如git remote add origin https://github.com/你的用户名/my-project.gitSSH需要先在本地生成并配置公钥好处是以后推送免输密码HTTPS在启用了Personal Access Token之后同样可以比较顺滑地推送。个人经验是SSH更省事一次配好长期受益。第三步推送本地内容git push -u origin main-u的作用是把本地main分支和远端main分支建立跟踪关系之后直接git push、git pull就能配对到这条分支不用每次重复写远端地址。以后每次写完代码就是两句话git add . git commit -m 写出提交说明 git push在我看来git push 就是这个工具链里的出口管道前端的暂存和提交都是为这个出口服务的。只要日常习惯保持了一小步一小步地提交推送时基本不会出大问题。8. 新手最常踩的坑commit消息混乱分支纠缠不清严格来说这一节不是命令教程而是我对几年git实操教训的总结。不少人在前面部分学得挺顺利一到真实项目里却手忙脚乱问题往往不在技术而在习惯。第一坑提交写得像流水账例如“更新”“修改”“改bug”。几次提交之后自己都看不懂之前做了什么。尽量遵循一句话前缀加内容说明的习惯fix(登录): 修复token过期后未跳转的问题、feat(商品): 新增库存预警字段。格式没有统一标准但至少让别人和自己一眼就懂。第二坑把大量无关改动打包成一次commit。这在代码评审时几乎没法review回退时也很痛苦。尽量让每次提交保持“单一目的”这样一条提交只对应一个问题或一个功能点。第三坑合并分支时不清楚当前HEAD在哪。执行git merge之前先git status确认所在分支不然可能把别人的分支合并到自己还没有准备好的位置上。第四坑使用git commit --amend时大家共同使用的分支上操作。多人协作分支上改历史提交几乎必然导致其他人拉取时冲突后端应只对自己的本地分支使用amend。第五坑git reset --hard前备份手感。我在真实项目里见过有人在未提交状态下直接reset导致一天工作消失。再强调一次先git stash或复制文件到临时目录再操作。第六坑为图省事想.all in把不该入库的内容.env、密钥、构建产物全推上去。前面第1节已经强调过分类原则实际执行时就靠 .gitignore 和白名单。这套操作在你日常写代码时用到的频次远比想象中高每次写代码前习惯性看git status写完一处就提交一个原子commit保持仓库历史的清爽度等回头找bug、做回退时会感谢自己。这一套流程走通你就不再是只会点IDE按钮的Git用户了。