新同事第一天入职组长让我抽个空把开发环境给他过一遍。我原本的计划特别朴素花二十分钟把 Git 的日常链路演示一遍能 clone、add、commit、push、pull先跑起来别出岔子就行。结果这位新同学第一句“Git 和 SVN 到底差在哪”就把我拽进了深水区二十分钟硬是讲成了一个半小时最后还顺手给组里沉淀了一份内部速查手册。后来我琢磨了一下这还真不是他基础差。绝大多数新人接触 Git 都会被同一个东西卡脖子一上来就背命令却不知道每一条命令背后到底发生了什么。命令背熟了遇到合并冲突、误操作、分支错乱照样两眼一抹黑。所以这篇东西我不打算写成命令大全而是把这次“即兴培训”里最值钱的几块沉淀下来——先建正确的 Git 心智模型再讲日常命令怎么落手然后拆分支策略、手把手解一次冲突最后给出一整套事故现场的恢复方案。不管是带新人的老员工还是刚入职正被 Git 反复折腾的同学应该都能从里面找到可以直接拿去用的东西。1. 为什么我给新人讲 Git先花半小时讲这三个关键概念我坚持认为新手学 Git 的第一个障碍不是命令而是脑子里的模型不对。模型对了命令看一眼就能记住模型不对背一百条命令也是散装知识错一次就崩盘。1.1 先把“网盘思维”纠正成“快照思维”很多新人会把 Git 理解成“带历史版本的网盘”反正能传、能存、能拉回来。这个说法不能算全错但它会埋不少暗坑。你要是真把它当网盘用第一次遇到冲突或者提交被覆盖的时候根本不知道去哪找线索。我当时是这么给我那位新同事解释的网盘同步的是“文件的最新状态”而 Git 记录的是“项目在每个提交时刻的完整快照”。你可以把每次 commit 想象成给整个项目拍一张照片照片里不止有文件内容还有拍摄人、拍摄时间和拍摄理由。想回到任何时候就拿出来对应那张照片看一眼项目源代码分毫不差地恢复成当时的样子。这个认知是所有操作的根。理解了“快照”你才会明白为什么 Git 几乎不会丢数据——每次提交都被完整保存在本地仓库里只要你没有主动清理历史上做过的所有动作都还在误删了分支都有机会捞回来。我后边将讲的 reflog 恢复就是建立在这个基础上的。1.2 工作区、暂存区、本地仓库、远程仓库到底各管什么我给新人画过一张特别土的图但效果好得出奇。把项目历程想象成一条流水线工作区就是你的草稿本所有正在改的代码躺在这里。暂存区一个检视台。草稿本上有十处改动你挑出要定稿的三处先放进检视台。本地仓库归档柜。放进来的提交就是一张张已经装订好的档案随时可取。远程仓库团队公用的档案室。别人可以从这里借阅档案你也可以把本地归档推上去共享。对应到 Git 的状态一个文件会经历四种身份未跟踪、已修改、已暂存、已提交。新手最容易不耐烦的就是“我都改完了为什么不能直接保存还要先 add 再 commit”答案就是暂存区给了你一个“选择性提交”的能力。很多时候你在一个文件里同时改了正经功能和调试日志没有暂存区的话这两类修改就只能捆在一起提交将来想单独回溯其中一部分就特别痛苦。能力越大责任越大这一步真不能省。提示让新人每天开工第一件事就是敲一遍git status看看当前在哪个分支、工作区有没有遗留的修改。这个习惯能避免大半“我明明没动这个文件它怎么变了”的灵异事件。1.3 分支是便宜的平行世界不是危险的玩具快照模型理解之后分支就顺理成章了。每一个分支本质上是一条独立的快照时间线切换分支就是让工作区恢复到另一条时间线上的某一个状态。我给新同事打了个比方主分支是团队的“正史”大家约定俗成的稳定版本都记录在这条线上。功能分支就是平行宇宙——你在里面怎么折腾都不影响正史折腾成功了再合并回来折腾失败了直接丢弃一切当没发生过。新人的观念误区是觉得“分支很重、很危险”。实际上 Git 的分支就是一个指向某次提交的指针创建分支只是多写了一个引用几乎不占任何成本。多开分支完全不心疼真正需要警惕的只有一件事不要把别人正在用的共享分支乱改历史。这个原则后边讲 rebase 的时候会再详细说。2. 新人第二天就能上手的 8 条日常命令概念讲完就该动手了。我的原则是“少而精”先让他把一条主链路跑顺再逐步扩展。链路是克隆 → 查看状态 → 暂存 → 提交 → 推送 → 拉取 → 看历史。2.1 克隆项目用 git clone 而不是下载 ZIP新同事来了第一件事永远是拿代码。很多人习惯去网页上点“下载 ZIP”我明确反对。ZIP 下载下来的只是一个目录快照没有历史记录没有分支信息它和真正的“把这个仓库拉到本地”是两回事。正确的是用 clone它会把你需要的完整历史都搬到本地git clone gitexample.com:team/project.git cd project克隆完成后可以看看本地生成了哪些分支git branch -a如果仓库特别大我只想快速看代码的时候会用--depth 1做浅克隆只拉最新一版省时间也省磁盘。但浅克隆对日常开发不友好没有历史就没法追溯问题所以我只把这个当“体验模式”推荐正经干活还是老老实实全量克隆。2.2 提交三连add、commit、push 的正确用法这是全组使用频率最高的一串命令值得讲细一点。先看最基础的三步git add . # 把改动加入暂存区 git commit -m feat: 添加支付回调处理 # 提交 git push # 推送到远程对新人我要强调两点。第一git add不建议无脑git add .除非你非常确定当前改动都是干净的。我习惯是先用git status和git diff看清楚改了啥再决定怎么加。需要一批一批提交的时候git add -p可以进入交互模式逐个 hunk 决定要不要暂存配合暂存区的存在意义非常好用。第二提交信息是写给未来的自己和其他同事看的。我要求组里的信息格式是“类型: 一句话描述”比如fix: 修复登录态过期问题、refactor: 抽取通用分页组件。这样看历史的时候扫一眼就明白每个提交干了什么。每次提交只干一件事尽量做小步提交这是所有 Git 老手都会强调的习惯。小提交让回滚更精准也让冲突定位更容易。说到git push首次推送到一个新分支时我让新人加-u参数git push -u origin feature/payment-u全称是--set-upstream它的作用是让本地分支和远程分支建立跟踪关系。以后在这个分支上直接敲git push、git pull就够了不用每次带一大串参数。2.3 pull 的两种姿势以及我为什么推荐 --rebasegit pull其实是两步动作的合成先git fetch把远程的最新提交拉下来再做一次合并把远程提交接入当前分支。问题就出在这个“合并”上默认策略会生成一个 merge commit时间长了你可能在本地分支上看到一堆“Merge remote-tracking branch”之类的噪音节点。我给新同事推荐的姿势是在自己私有分支上拉取时加--rebase。git pull --rebaserebase 的意思是把你本地还没推送的提交先摘下来等远程的新提交回来后再一个一个接上去。效果就是历史看起来像一条直线不会被莫名多出来的合并节点打乱。注意这样做的前提是你的工作区干净有未提交的修改会导致 rebase 无法进行需要先提交或暂存。那git pull的默认合并在什么时候用在共享分支上比如main分支我更倾向于让它生成 merge commit因为它忠实记录了“我和别人曾经并行修改过”这个事实。总结成一句场景推荐姿势理由私有功能分支git pull --rebase历史干净、线性方便阅读共享主分支git pull默认合并保留并行开发痕迹少动别人历史2.4 两条“看东西”的命令status 和 log很多新人不知道 Git 自带一套挺友好的信息查询系统。git status告诉你“现在处于什么状态”git log告诉你“历史发生了什么”。日常就够用的两条git status -sb git log --oneline --graph --decorate -10-sb是精简模式-s输出紧凑的改动列表-b显示当前分支以及和远程的领先/落后关系。一眼就能看出本地是不是有没推送的提交。git log加--graph会用字符画出分支合并路线配合--oneline每条提交只占一行非常直观。我给新人建议直接 alias 成短命令git config --global alias.st status -sb git config --global alias.lg log --oneline --graph --decorate --all以后敲git st、git lg就能更快地进入状态。这俩 alias 几乎是我安利过最多人的两条。3. 分支策略这样讲新同事才敢放心开分支3.1 为什么主分支不是用来直接写代码的我带过的团队里凡是允许直接在main上写代码的早晚都会闹一次“线上炸了但没人知道是哪次提交搞的”事故。主分支承担的是团队交付物的稳定基线它是所有人的共同底座在上面直接提交相当于把入口敞开任何人的半成品都会瞬间暴露给全组。所以我在组里立了一条最简单但也最有效的规定main永远保持可发布状态任何开发都从main拉出新分支绝不在主分支上直接写业务。新同事一开始觉得麻烦但经历过一次“一个坏提交让全组都拉不下来代码”的现场后就都服气了。3.2 一套可以照抄的功能分支操作流我推荐给新人的是一套朴素的分支命名和流转流程没有复杂的工作流概念小团队和个人项目都够用。分支命名按用途区分分支前缀用途示例feature/新功能feature/paymentbugfix/缺陷修复bugfix/login-expirechore/杂务、重构、依赖升级chore/upgrade-utils整套操作流程如下# 1. 先把主分支更新到最新 git switch main git pull # 2. 从最新 main 切出新分支 git switch -c feature/payment # 3. 开发过程中小步提交 git add -p git commit -m feat: 接入支付回调 # 4. 推送到远程并建立跟踪 git push -u origin feature/payment # 5. 功能完成后合并回 main git switch main git pull git merge --no-ff feature/payment这里面的--no-ff值得单独解释。即使功能分支上只有一个提交--no-ff也会强制生成一个合并节点把这个功能“装入”主分支的动作单独记录一笔。这么做的好处是将来一眼能看到“这个功能是哪个合并点进主线”回滚也方便——直接 revert 那个合并节点就行。相比之下快进合并虽然在历史上没有岔路但功能的边界会模糊。合并完成后顺手删除已经没用的分支git branch -d feature/payment git push origin --delete feature/payment本地删除用-d如果分支没被合并会提示并阻止删除这是 Git 在保护你。远程的分支删掉是避免分支越积越多看着整洁也不容易混淆。3.3 让新同事亲眼看到分支的全家福讲分支只靠抽象概念是记不牢的我习惯让新人跑一遍git lg看看真实的提交图。类似这样的输出* 9d8f2a1 (HEAD - feature/payment) Merge main into feature/payment |\ | * c4e9b03 (main) fix: 调整首页样式 * | 72fa01c feat: 接入支付渠道回调 * | 5b2e09d feat: 新增支付订单表 |/ * a1d3f77 feat: 初始化支付模块看到这张图之后新人对“分支是时间线的分叉与汇合”这个感知会立刻清晰起来。分叉的部分是并行开发汇合的点就是一次合并。我一直觉得读提交图的能力是 Git 学习者从入门到进阶的一道分水岭。4. 合并冲突手把手拆解一次演示胜过十遍口述4.1 冲突不是事故而是 Git 把决定权交还给你新人第一次看到“CONFLICT”这个单词时手心都会冒汗。我得先给他们定心丸冲突不是坏事恰恰说明 Git 发现了它无法独自裁决的地方。它再聪明也是个程序当两个分支在同一行代码上有不同修改它不知道该听谁的只能把你请出来做决定。一个特别贴切的类比你让两个同事分别在同一页 PPT 上修改改完合到一起编辑不可能同时保留两个版本他必须找你确认到底以谁为准。Git 的冲突提示就是那个编辑在旁边举着牌子等你拍板。4.2 手工解决一次冲突的完整流程我给新人演示冲突解决时习惯造一个很小的场景两个分支都改了同一个文件然后合并。冲突发生后先看git statusGit 会标出哪些文件处于未合并状态git merge feature/payment # Auto-merging payment.go # CONFLICT (content): Merge conflict in payment.go打开那个文件会看到冲突标记 HEAD currentVersion : v1 currentVersion : v2 feature/payment这个标记的意思是 HEAD到之间是当前分支的版本到 feature/payment之间是合并进来那个分支的版本。你需要做的是选择保留哪个、删掉哪个或者两个都要再组合一下然后把三组标记行全部删掉。解决完毕之后把文件标记为已解决并提交git add payment.go git commit这里的git commit不需要带-m因为 Git 会帮你生成一条合并提交信息直接确认即可。注意如果解决到一半发现自己处理不了或者改乱了随时可以用git merge --abort回到合并之前的状态。这不是认怂是止损。另外有一种冲突是文本合并解决不了的——二进制文件冲突比如图片、打包产物。Git 没法帮你逐行合并你只能二选一。这时可以用git checkout --ours path/to/file # 保留当前分支版本 git checkout --theirs path/to/file # 保留合并进来的版本但要提醒一句在合并过程中“ours”指当前所在分支“theirs”指被合并进来的分支方向和平时直觉可能正好相反。用之前先想清楚自己在哪。4.3 merge 和 rebase 怎么选一张表说清楚如果说矛盾的命令给新手恐惧那 merge 和 rebase 的选择给新手的多半是困惑。我在组里要求新人记住下面这张表场景用什么为什么把功能分支合并回主分支merge保留一次合并节点记录功能进入主线的边界同步主分支新代码到自己的功能分支rebase让功能分支历史线性减少难懂的合并节点已经推送且可能被其他人使用的分支一律 mergerebase 会重写历史让别人的本地记录失配最后一条是铁律绝不 rebase 一个已经推送到远程、并且可能被别人拉取过的共享分支。rebase 会改写提交的哈希你本地重写一次队友那边原有的引用就对不上了再次拉取时 Git 会误以为出现了分叉然后制造出一堆重复提交或者让队友需要手工处理场面很难看。私有分支反正只有你自己在用随便 rebase追求历史干净没问题。5. Git 事故现场新人必会的五种恢复操作新人出事故不可怕可怕的是不知道有多少种后悔药。我特意给新同事准备了一场“模拟事故演练”在一个练习仓库里故意制造各种错误然后一个个救回来。这里挑五个最典型的分享给大家。5.1 提交信息写错了、文件漏传了用 commit --amend 补救刚提交完发现信息拼错了或者忘了把一个文件加进来这种小事故几乎每个人都遇过。如果提交还没推送出去处理很简单git add forgot-file.go git commit --amend--amend的含义是“用一个新的提交替换当前最后一个提交”它会把暂存区里还没提交的改动一并合进去同时给你机会修改提交信息。注意amend 本质上也是重写历史所以它同样只适用于尚未推送的提交。如果已经推送了需要非常谨慎不建议新人碰。5.2 提交完了想反悔reset 三兄弟怎么选git reset会根据参数的不同把当前分支的 HEAD 挪到指定提交并决定要不要同步重置暂存区和工作区参数影响范围使用场景--soft只移动 HEAD暂存区和工作区都保留提交信息想重写、提交粒度想重分--mixed默认移动 HEAD 并清空暂存区工作区改动保留想取消暂存但不丢代码--hardHEAD、暂存区、工作区全部重置本地改乱且确定不想要了举例你发现刚才提交里混进了一段调试代码想重新组织提交git reset --soft HEAD~1HEAD 回到上一个提交本地代码还在暂存区也还保留你可以调整后再提交。而--hard是最危险的它会连工作区的未提交修改一起删掉。用完git reset --hard发现代码没了唯一救星就是后面要说的 reflog。还需要强调已经推送出去的提交千万不能用 reset 然后强推的方式抹除尤其不在共享分支上这么干。这是团队协作的大忌宁可新增一个提交去把错误翻篇。5.3 已经推送到远程的坏提交用 revert 翻篇遇到已经推送的坏提交正确姿势是git revert。它是“反着应用一次修改”生成一个新的提交把目标提交造成的影响抵消掉而不去改动历史git revert 8f3a2e1这种方式的优点是对共享分支非常安全因为它不重写任何已有提交其他同事拉取时只需要正常合并。坏提交本身留在历史上想看还能看到但它造成的效果已经被新提交抵消。这是处理远程坏提交的首选没有之一。5.4 分支被删、reset 过头reflog 就是后悔药分支删了、reset 错了只要提交对象还在就没到绝境。Git 有一个隐藏的日志叫 reflog它记录了 HEAD 指针每一次移动的历史。哪怕是“删掉一个分支”这种操作分支指向的提交对象也会在 reflog 里留痕git reflog # 8f3a2e1 HEAD{0}: reset: moving to HEAD~2 # c4e9b03 HEAD{1}: commit: feat: 新增支付模块 # a1d3f77 HEAD{2}: branch: Created from main从输出里找到你想要回到的提交哈希然后基于它新建一条分支一切就能救回来git switch -c recover-branch c4e9b03我给新同事的叮嘱是reflog 是比备份更可靠的存在只要不跑git gc主动清理默认情况下它会保留一段时间。所以遇到误操作第一反应不是慌张而是git reflog。5.5 改到一半要切分支stash 临时藏起现场最常发生的事故不是提交错了而是“我改到一半突然要去修个紧急 bug”。不能带着未提交的修改直接切分支因为 Git 会提示工作区不干净。这时候用 stash 把现场打包存起来git stash git switch main # 紧急修复完成后再回来 git switch feature/payment git stash popgit stash把当前未提交的修改保存到一个暂存栈里工作区恢复干净。git stash pop会把栈顶的修改重新应用回工作区。如果同时存了多个现场可以用git stash list查看用git stash apply stash{1}指定应用某一个。这个命令不复杂但关键时刻能省下很多“完了我改了半天的代码要被覆盖了”的绝望。6. 让新人从“抄命令”进化到“独立排障”6.1 第一课学会读懂 Git 给你的提示我发现很多新人遇到问题第一反应是关掉终端切换软件重来。我不让他们这么做。Git 最友好的一面就是它非常话痨几乎每个错误提示都在告诉你下一步该怎么走。举个例子新手第一天就会遇到 push 被拒To github.com:example/project.git ! [rejected] main - main (fetch first) error: failed to push some refs hint: Updates were rejected because the remote contains work hint: you do not have locally.翻译成人话就是远程仓库有了你没有的提交你的推送会被覆盖别人的内容所以被拒绝了。解决办法其实就是提示里隐含的——先把远程的拉下来合并再推送。我让新人养成的习惯是报错之后先读三遍屏幕上的英文提示你至少能获取 80% 的解决线索。6.2 建一个随便折腾的本地练习场我强烈建议新人在自己的电脑上建一个专门拿来“搞破坏”的练习仓库mkdir git-playground cd git-playground git init echo hello test.txt git add . git commit -m first在这个目录里随便 rebase、reset、删分支、制造冲突什么姿势都可以试。反正是一堆废代码没有任何心理负担。我那位新同事就是在这样的沙盒里反复折腾了两天把冲突标记、reflog、stash 都亲手玩了一遍之后就再也不怕真实的项目操作了。这个方法比任何教程都管用因为肌肉记忆只能靠动手建立。6.3 我的最后一条建议维护一份“事故台账”我带过不少新人发现一个很有意思的规律同一个错误几乎每个人都会踩一遍。所以我在组里给新人的最后一个任务是建一个文档名字就叫“我的 Git 事故台账”。格式很简单三列现象、原因、解决办法。比如记一条“push 被拒 → 远程有新提交我没拉 → 先 git pull --rebase 再 push”。这招看起来特别土但效果奇好。新人遇到新问题先查台账查不到再问人解决后补一笔。三个月下来那份文档就是他自己最珍贵的一手经验集比任何网上教程都贴合他的实际工作场景。我自己的 Git 水平也远说不上顶尖但这么多年下来最大的体会是只要模型正确、恢复手段熟练Git 就是那个“怎么折腾都摔不死”的工具。新同事从“怕 Git”到“把 Git 当朋友”往往也就是一周的事。关键是别让他一开始就淹没在命令的海洋里先把主干打通剩下的交给时间去积累。
新同事第一天入职组长让我抽个空把开发环境给他过一遍。我原本的计划特别朴素花二十分钟把 Git 的日常链路演示一遍能 clone、add、commit、push、pull先跑起来别出岔子就行。结果这位新同学第一句“Git 和 SVN 到底差在哪”就把我拽进了深水区二十分钟硬是讲成了一个半小时最后还顺手给组里沉淀了一份内部速查手册。后来我琢磨了一下这还真不是他基础差。绝大多数新人接触 Git 都会被同一个东西卡脖子一上来就背命令却不知道每一条命令背后到底发生了什么。命令背熟了遇到合并冲突、误操作、分支错乱照样两眼一抹黑。所以这篇东西我不打算写成命令大全而是把这次“即兴培训”里最值钱的几块沉淀下来——先建正确的 Git 心智模型再讲日常命令怎么落手然后拆分支策略、手把手解一次冲突最后给出一整套事故现场的恢复方案。不管是带新人的老员工还是刚入职正被 Git 反复折腾的同学应该都能从里面找到可以直接拿去用的东西。1. 为什么我给新人讲 Git先花半小时讲这三个关键概念我坚持认为新手学 Git 的第一个障碍不是命令而是脑子里的模型不对。模型对了命令看一眼就能记住模型不对背一百条命令也是散装知识错一次就崩盘。1.1 先把“网盘思维”纠正成“快照思维”很多新人会把 Git 理解成“带历史版本的网盘”反正能传、能存、能拉回来。这个说法不能算全错但它会埋不少暗坑。你要是真把它当网盘用第一次遇到冲突或者提交被覆盖的时候根本不知道去哪找线索。我当时是这么给我那位新同事解释的网盘同步的是“文件的最新状态”而 Git 记录的是“项目在每个提交时刻的完整快照”。你可以把每次 commit 想象成给整个项目拍一张照片照片里不止有文件内容还有拍摄人、拍摄时间和拍摄理由。想回到任何时候就拿出来对应那张照片看一眼项目源代码分毫不差地恢复成当时的样子。这个认知是所有操作的根。理解了“快照”你才会明白为什么 Git 几乎不会丢数据——每次提交都被完整保存在本地仓库里只要你没有主动清理历史上做过的所有动作都还在误删了分支都有机会捞回来。我后边将讲的 reflog 恢复就是建立在这个基础上的。1.2 工作区、暂存区、本地仓库、远程仓库到底各管什么我给新人画过一张特别土的图但效果好得出奇。把项目历程想象成一条流水线工作区就是你的草稿本所有正在改的代码躺在这里。暂存区一个检视台。草稿本上有十处改动你挑出要定稿的三处先放进检视台。本地仓库归档柜。放进来的提交就是一张张已经装订好的档案随时可取。远程仓库团队公用的档案室。别人可以从这里借阅档案你也可以把本地归档推上去共享。对应到 Git 的状态一个文件会经历四种身份未跟踪、已修改、已暂存、已提交。新手最容易不耐烦的就是“我都改完了为什么不能直接保存还要先 add 再 commit”答案就是暂存区给了你一个“选择性提交”的能力。很多时候你在一个文件里同时改了正经功能和调试日志没有暂存区的话这两类修改就只能捆在一起提交将来想单独回溯其中一部分就特别痛苦。能力越大责任越大这一步真不能省。提示让新人每天开工第一件事就是敲一遍git status看看当前在哪个分支、工作区有没有遗留的修改。这个习惯能避免大半“我明明没动这个文件它怎么变了”的灵异事件。1.3 分支是便宜的平行世界不是危险的玩具快照模型理解之后分支就顺理成章了。每一个分支本质上是一条独立的快照时间线切换分支就是让工作区恢复到另一条时间线上的某一个状态。我给新同事打了个比方主分支是团队的“正史”大家约定俗成的稳定版本都记录在这条线上。功能分支就是平行宇宙——你在里面怎么折腾都不影响正史折腾成功了再合并回来折腾失败了直接丢弃一切当没发生过。新人的观念误区是觉得“分支很重、很危险”。实际上 Git 的分支就是一个指向某次提交的指针创建分支只是多写了一个引用几乎不占任何成本。多开分支完全不心疼真正需要警惕的只有一件事不要把别人正在用的共享分支乱改历史。这个原则后边讲 rebase 的时候会再详细说。2. 新人第二天就能上手的 8 条日常命令概念讲完就该动手了。我的原则是“少而精”先让他把一条主链路跑顺再逐步扩展。链路是克隆 → 查看状态 → 暂存 → 提交 → 推送 → 拉取 → 看历史。2.1 克隆项目用 git clone 而不是下载 ZIP新同事来了第一件事永远是拿代码。很多人习惯去网页上点“下载 ZIP”我明确反对。ZIP 下载下来的只是一个目录快照没有历史记录没有分支信息它和真正的“把这个仓库拉到本地”是两回事。正确的是用 clone它会把你需要的完整历史都搬到本地git clone gitexample.com:team/project.git cd project克隆完成后可以看看本地生成了哪些分支git branch -a如果仓库特别大我只想快速看代码的时候会用--depth 1做浅克隆只拉最新一版省时间也省磁盘。但浅克隆对日常开发不友好没有历史就没法追溯问题所以我只把这个当“体验模式”推荐正经干活还是老老实实全量克隆。2.2 提交三连add、commit、push 的正确用法这是全组使用频率最高的一串命令值得讲细一点。先看最基础的三步git add . # 把改动加入暂存区 git commit -m feat: 添加支付回调处理 # 提交 git push # 推送到远程对新人我要强调两点。第一git add不建议无脑git add .除非你非常确定当前改动都是干净的。我习惯是先用git status和git diff看清楚改了啥再决定怎么加。需要一批一批提交的时候git add -p可以进入交互模式逐个 hunk 决定要不要暂存配合暂存区的存在意义非常好用。第二提交信息是写给未来的自己和其他同事看的。我要求组里的信息格式是“类型: 一句话描述”比如fix: 修复登录态过期问题、refactor: 抽取通用分页组件。这样看历史的时候扫一眼就明白每个提交干了什么。每次提交只干一件事尽量做小步提交这是所有 Git 老手都会强调的习惯。小提交让回滚更精准也让冲突定位更容易。说到git push首次推送到一个新分支时我让新人加-u参数git push -u origin feature/payment-u全称是--set-upstream它的作用是让本地分支和远程分支建立跟踪关系。以后在这个分支上直接敲git push、git pull就够了不用每次带一大串参数。2.3 pull 的两种姿势以及我为什么推荐 --rebasegit pull其实是两步动作的合成先git fetch把远程的最新提交拉下来再做一次合并把远程提交接入当前分支。问题就出在这个“合并”上默认策略会生成一个 merge commit时间长了你可能在本地分支上看到一堆“Merge remote-tracking branch”之类的噪音节点。我给新同事推荐的姿势是在自己私有分支上拉取时加--rebase。git pull --rebaserebase 的意思是把你本地还没推送的提交先摘下来等远程的新提交回来后再一个一个接上去。效果就是历史看起来像一条直线不会被莫名多出来的合并节点打乱。注意这样做的前提是你的工作区干净有未提交的修改会导致 rebase 无法进行需要先提交或暂存。那git pull的默认合并在什么时候用在共享分支上比如main分支我更倾向于让它生成 merge commit因为它忠实记录了“我和别人曾经并行修改过”这个事实。总结成一句场景推荐姿势理由私有功能分支git pull --rebase历史干净、线性方便阅读共享主分支git pull默认合并保留并行开发痕迹少动别人历史2.4 两条“看东西”的命令status 和 log很多新人不知道 Git 自带一套挺友好的信息查询系统。git status告诉你“现在处于什么状态”git log告诉你“历史发生了什么”。日常就够用的两条git status -sb git log --oneline --graph --decorate -10-sb是精简模式-s输出紧凑的改动列表-b显示当前分支以及和远程的领先/落后关系。一眼就能看出本地是不是有没推送的提交。git log加--graph会用字符画出分支合并路线配合--oneline每条提交只占一行非常直观。我给新人建议直接 alias 成短命令git config --global alias.st status -sb git config --global alias.lg log --oneline --graph --decorate --all以后敲git st、git lg就能更快地进入状态。这俩 alias 几乎是我安利过最多人的两条。3. 分支策略这样讲新同事才敢放心开分支3.1 为什么主分支不是用来直接写代码的我带过的团队里凡是允许直接在main上写代码的早晚都会闹一次“线上炸了但没人知道是哪次提交搞的”事故。主分支承担的是团队交付物的稳定基线它是所有人的共同底座在上面直接提交相当于把入口敞开任何人的半成品都会瞬间暴露给全组。所以我在组里立了一条最简单但也最有效的规定main永远保持可发布状态任何开发都从main拉出新分支绝不在主分支上直接写业务。新同事一开始觉得麻烦但经历过一次“一个坏提交让全组都拉不下来代码”的现场后就都服气了。3.2 一套可以照抄的功能分支操作流我推荐给新人的是一套朴素的分支命名和流转流程没有复杂的工作流概念小团队和个人项目都够用。分支命名按用途区分分支前缀用途示例feature/新功能feature/paymentbugfix/缺陷修复bugfix/login-expirechore/杂务、重构、依赖升级chore/upgrade-utils整套操作流程如下# 1. 先把主分支更新到最新 git switch main git pull # 2. 从最新 main 切出新分支 git switch -c feature/payment # 3. 开发过程中小步提交 git add -p git commit -m feat: 接入支付回调 # 4. 推送到远程并建立跟踪 git push -u origin feature/payment # 5. 功能完成后合并回 main git switch main git pull git merge --no-ff feature/payment这里面的--no-ff值得单独解释。即使功能分支上只有一个提交--no-ff也会强制生成一个合并节点把这个功能“装入”主分支的动作单独记录一笔。这么做的好处是将来一眼能看到“这个功能是哪个合并点进主线”回滚也方便——直接 revert 那个合并节点就行。相比之下快进合并虽然在历史上没有岔路但功能的边界会模糊。合并完成后顺手删除已经没用的分支git branch -d feature/payment git push origin --delete feature/payment本地删除用-d如果分支没被合并会提示并阻止删除这是 Git 在保护你。远程的分支删掉是避免分支越积越多看着整洁也不容易混淆。3.3 让新同事亲眼看到分支的全家福讲分支只靠抽象概念是记不牢的我习惯让新人跑一遍git lg看看真实的提交图。类似这样的输出* 9d8f2a1 (HEAD - feature/payment) Merge main into feature/payment |\ | * c4e9b03 (main) fix: 调整首页样式 * | 72fa01c feat: 接入支付渠道回调 * | 5b2e09d feat: 新增支付订单表 |/ * a1d3f77 feat: 初始化支付模块看到这张图之后新人对“分支是时间线的分叉与汇合”这个感知会立刻清晰起来。分叉的部分是并行开发汇合的点就是一次合并。我一直觉得读提交图的能力是 Git 学习者从入门到进阶的一道分水岭。4. 合并冲突手把手拆解一次演示胜过十遍口述4.1 冲突不是事故而是 Git 把决定权交还给你新人第一次看到“CONFLICT”这个单词时手心都会冒汗。我得先给他们定心丸冲突不是坏事恰恰说明 Git 发现了它无法独自裁决的地方。它再聪明也是个程序当两个分支在同一行代码上有不同修改它不知道该听谁的只能把你请出来做决定。一个特别贴切的类比你让两个同事分别在同一页 PPT 上修改改完合到一起编辑不可能同时保留两个版本他必须找你确认到底以谁为准。Git 的冲突提示就是那个编辑在旁边举着牌子等你拍板。4.2 手工解决一次冲突的完整流程我给新人演示冲突解决时习惯造一个很小的场景两个分支都改了同一个文件然后合并。冲突发生后先看git statusGit 会标出哪些文件处于未合并状态git merge feature/payment # Auto-merging payment.go # CONFLICT (content): Merge conflict in payment.go打开那个文件会看到冲突标记 HEAD currentVersion : v1 currentVersion : v2 feature/payment这个标记的意思是 HEAD到之间是当前分支的版本到 feature/payment之间是合并进来那个分支的版本。你需要做的是选择保留哪个、删掉哪个或者两个都要再组合一下然后把三组标记行全部删掉。解决完毕之后把文件标记为已解决并提交git add payment.go git commit这里的git commit不需要带-m因为 Git 会帮你生成一条合并提交信息直接确认即可。注意如果解决到一半发现自己处理不了或者改乱了随时可以用git merge --abort回到合并之前的状态。这不是认怂是止损。另外有一种冲突是文本合并解决不了的——二进制文件冲突比如图片、打包产物。Git 没法帮你逐行合并你只能二选一。这时可以用git checkout --ours path/to/file # 保留当前分支版本 git checkout --theirs path/to/file # 保留合并进来的版本但要提醒一句在合并过程中“ours”指当前所在分支“theirs”指被合并进来的分支方向和平时直觉可能正好相反。用之前先想清楚自己在哪。4.3 merge 和 rebase 怎么选一张表说清楚如果说矛盾的命令给新手恐惧那 merge 和 rebase 的选择给新手的多半是困惑。我在组里要求新人记住下面这张表场景用什么为什么把功能分支合并回主分支merge保留一次合并节点记录功能进入主线的边界同步主分支新代码到自己的功能分支rebase让功能分支历史线性减少难懂的合并节点已经推送且可能被其他人使用的分支一律 mergerebase 会重写历史让别人的本地记录失配最后一条是铁律绝不 rebase 一个已经推送到远程、并且可能被别人拉取过的共享分支。rebase 会改写提交的哈希你本地重写一次队友那边原有的引用就对不上了再次拉取时 Git 会误以为出现了分叉然后制造出一堆重复提交或者让队友需要手工处理场面很难看。私有分支反正只有你自己在用随便 rebase追求历史干净没问题。5. Git 事故现场新人必会的五种恢复操作新人出事故不可怕可怕的是不知道有多少种后悔药。我特意给新同事准备了一场“模拟事故演练”在一个练习仓库里故意制造各种错误然后一个个救回来。这里挑五个最典型的分享给大家。5.1 提交信息写错了、文件漏传了用 commit --amend 补救刚提交完发现信息拼错了或者忘了把一个文件加进来这种小事故几乎每个人都遇过。如果提交还没推送出去处理很简单git add forgot-file.go git commit --amend--amend的含义是“用一个新的提交替换当前最后一个提交”它会把暂存区里还没提交的改动一并合进去同时给你机会修改提交信息。注意amend 本质上也是重写历史所以它同样只适用于尚未推送的提交。如果已经推送了需要非常谨慎不建议新人碰。5.2 提交完了想反悔reset 三兄弟怎么选git reset会根据参数的不同把当前分支的 HEAD 挪到指定提交并决定要不要同步重置暂存区和工作区参数影响范围使用场景--soft只移动 HEAD暂存区和工作区都保留提交信息想重写、提交粒度想重分--mixed默认移动 HEAD 并清空暂存区工作区改动保留想取消暂存但不丢代码--hardHEAD、暂存区、工作区全部重置本地改乱且确定不想要了举例你发现刚才提交里混进了一段调试代码想重新组织提交git reset --soft HEAD~1HEAD 回到上一个提交本地代码还在暂存区也还保留你可以调整后再提交。而--hard是最危险的它会连工作区的未提交修改一起删掉。用完git reset --hard发现代码没了唯一救星就是后面要说的 reflog。还需要强调已经推送出去的提交千万不能用 reset 然后强推的方式抹除尤其不在共享分支上这么干。这是团队协作的大忌宁可新增一个提交去把错误翻篇。5.3 已经推送到远程的坏提交用 revert 翻篇遇到已经推送的坏提交正确姿势是git revert。它是“反着应用一次修改”生成一个新的提交把目标提交造成的影响抵消掉而不去改动历史git revert 8f3a2e1这种方式的优点是对共享分支非常安全因为它不重写任何已有提交其他同事拉取时只需要正常合并。坏提交本身留在历史上想看还能看到但它造成的效果已经被新提交抵消。这是处理远程坏提交的首选没有之一。5.4 分支被删、reset 过头reflog 就是后悔药分支删了、reset 错了只要提交对象还在就没到绝境。Git 有一个隐藏的日志叫 reflog它记录了 HEAD 指针每一次移动的历史。哪怕是“删掉一个分支”这种操作分支指向的提交对象也会在 reflog 里留痕git reflog # 8f3a2e1 HEAD{0}: reset: moving to HEAD~2 # c4e9b03 HEAD{1}: commit: feat: 新增支付模块 # a1d3f77 HEAD{2}: branch: Created from main从输出里找到你想要回到的提交哈希然后基于它新建一条分支一切就能救回来git switch -c recover-branch c4e9b03我给新同事的叮嘱是reflog 是比备份更可靠的存在只要不跑git gc主动清理默认情况下它会保留一段时间。所以遇到误操作第一反应不是慌张而是git reflog。5.5 改到一半要切分支stash 临时藏起现场最常发生的事故不是提交错了而是“我改到一半突然要去修个紧急 bug”。不能带着未提交的修改直接切分支因为 Git 会提示工作区不干净。这时候用 stash 把现场打包存起来git stash git switch main # 紧急修复完成后再回来 git switch feature/payment git stash popgit stash把当前未提交的修改保存到一个暂存栈里工作区恢复干净。git stash pop会把栈顶的修改重新应用回工作区。如果同时存了多个现场可以用git stash list查看用git stash apply stash{1}指定应用某一个。这个命令不复杂但关键时刻能省下很多“完了我改了半天的代码要被覆盖了”的绝望。6. 让新人从“抄命令”进化到“独立排障”6.1 第一课学会读懂 Git 给你的提示我发现很多新人遇到问题第一反应是关掉终端切换软件重来。我不让他们这么做。Git 最友好的一面就是它非常话痨几乎每个错误提示都在告诉你下一步该怎么走。举个例子新手第一天就会遇到 push 被拒To github.com:example/project.git ! [rejected] main - main (fetch first) error: failed to push some refs hint: Updates were rejected because the remote contains work hint: you do not have locally.翻译成人话就是远程仓库有了你没有的提交你的推送会被覆盖别人的内容所以被拒绝了。解决办法其实就是提示里隐含的——先把远程的拉下来合并再推送。我让新人养成的习惯是报错之后先读三遍屏幕上的英文提示你至少能获取 80% 的解决线索。6.2 建一个随便折腾的本地练习场我强烈建议新人在自己的电脑上建一个专门拿来“搞破坏”的练习仓库mkdir git-playground cd git-playground git init echo hello test.txt git add . git commit -m first在这个目录里随便 rebase、reset、删分支、制造冲突什么姿势都可以试。反正是一堆废代码没有任何心理负担。我那位新同事就是在这样的沙盒里反复折腾了两天把冲突标记、reflog、stash 都亲手玩了一遍之后就再也不怕真实的项目操作了。这个方法比任何教程都管用因为肌肉记忆只能靠动手建立。6.3 我的最后一条建议维护一份“事故台账”我带过不少新人发现一个很有意思的规律同一个错误几乎每个人都会踩一遍。所以我在组里给新人的最后一个任务是建一个文档名字就叫“我的 Git 事故台账”。格式很简单三列现象、原因、解决办法。比如记一条“push 被拒 → 远程有新提交我没拉 → 先 git pull --rebase 再 push”。这招看起来特别土但效果奇好。新人遇到新问题先查台账查不到再问人解决后补一笔。三个月下来那份文档就是他自己最珍贵的一手经验集比任何网上教程都贴合他的实际工作场景。我自己的 Git 水平也远说不上顶尖但这么多年下来最大的体会是只要模型正确、恢复手段熟练Git 就是那个“怎么折腾都摔不死”的工具。新同事从“怕 Git”到“把 Git 当朋友”往往也就是一周的事。关键是别让他一开始就淹没在命令的海洋里先把主干打通剩下的交给时间去积累。
 到底屏蔽了什么？Android Lint 检查机制与 TaoToken 配置验证)
