1. 为什么面试官总爱揪着Git不放面过十几场技术岗之后我发现一个规律简历上写熟悉Git的人一抓一大把但真正能说清楚merge和rebase区别的十个里面不超过三个。更别提让你现场描述一下reset三种模式的区别或者画一下分支合并后的提交图——很多人当场就卡壳了。这不是危言耸听。Git几乎是所有研发团队协作的基础设施面试官考察Git本质上不是在考你记不记得住命令而是在看你有没有真实的多人协作经验、有没有处理过代码冲突、懂不懂版本管理的底层逻辑。一个连cherry-pick都没用过的人很难让人相信他参与过正经的团队项目。这篇内容我打算把Git从会用到用明白这条线彻底捋一遍。不管你是刚接触版本控制的新手还是用了两三年但一直停留在add、commit、push三件套的阶段都能从中找到自己缺的那块拼图。我会用Mac环境下的实际操作来演示因为Mac的终端体验和文件系统跟Linux更接近很多命令行为跟Windows下确实有差异这一点后面会专门讲。整篇内容会覆盖Git的底层数据模型理解了这个命令就不用死记、日常开发中最容易踩的坑、分支管理的实战策略、面试高频问题的拆解以及Mac环境下特有的注意事项。你可以把它当成一份可以随时翻出来查的实战手册。2. 先搞懂Git到底在存什么命令就不用背了2.1 从快照这个核心概念说起大多数人学Git的方式是背命令git add是暂存git commit是提交git push是推送。背完之后遇到稍微复杂点的场景就懵了因为不知道这些命令背后到底在干什么。Git的本质是一个内容寻址的文件系统。每次你执行commitGit并不是记录你改了哪几行而是给当前所有文件拍一张完整的快照然后把这个快照的引用存起来。听起来很浪费空间对吧但Git用了两个关键机制来解决这个问题一是内容相同的文件只存一份通过SHA-1哈希去重二是没有变化的文件直接指向上一个版本的引用不重复存储。理解这一点非常重要。它意味着分支本质上只是一个指向某个提交的指针创建分支几乎不花任何代价。这就是为什么Git鼓励你频繁开分支而SVN时代大家都不愿意开分支——因为SVN的分支是实打实地复制目录。提交是不可变的。你没法修改一个提交只能创建一个新提交来替代它。commit --amend、rebase这些操作本质上都是在创建新提交旧提交虽然还在对象库里但已经没有任何引用指向它了。HEAD是一个特殊的指针它指向你当前所在的分支或者直接指向某个提交也就是分离头指针状态。2.2 三个区域的工作模型Git把文件的生命周期划分成三个区域这是理解所有命令的钥匙区域英文名存放位置对应操作工作区Working Directory你实际编辑文件的地方直接改文件暂存区Staging Area / Index.git/index文件git add版本库Repository.git/objects目录git commit文件在这三个区域之间流转。git add把工作区的改动写入暂存区git commit把暂存区的内容固化成一次提交存入版本库。git status之所以能告诉你哪些改了但没暂存哪些暂存了但没提交就是因为它在这三个区域之间做对比。我见过很多人搞不清楚git diff的几个变体其实只要记住对比的是哪两个区域就清楚了git diff工作区 vs 暂存区还没add的改动git diff --cached暂存区 vs 版本库add了但没commit的改动git diff HEAD工作区 vs 版本库所有还没提交的改动2.3 Mac上安装与初始配置的坑Mac自带了一个Git但那个版本通常比较老而且跟Xcode命令行工具绑定在一起。我建议直接用Homebrew装一个独立的brew install git装完之后确认一下路径确保用的是Homebrew装的而不是系统自带的which git # 应该输出 /opt/homebrew/bin/gitApple Silicon或 /usr/local/bin/gitIntel初始配置里最容易忽略的是换行符处理。Mac和Linux用LFWindows用CRLF如果不配置跨平台协作时会出现整个文件都显示被修改的情况。Mac用户建议这样设置git config --global core.autocrlf input这个配置的含义是提交时把CRLF转成LF检出时不转换。这样在Mac上编辑的文件提交到仓库里永远是LF跟Linux服务器保持一致。另外强烈建议配一个好看的日志输出别名后面排查问题时会大量用到git config --global alias.lg log --graph --prettyformat:%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%an%Creset --abbrev-commit配好之后敲git lg就能看到带分支图形的彩色日志比默认的git log好用太多。3. 日常开发中真正高频的操作场景3.1 提交历史怎么整理才不像一坨乱麻新手最常见的提交习惯是写一点东西就commit一次提交信息全是updatefix修改。等到要提PR或者排查问题时翻提交历史跟看天书一样。我的建议是养成原子提交的习惯每次提交只做一件事提交信息用动词对象原因的格式。比如fix: 修复用户登录时token过期未刷新的问题 feat: 新增订单导出Excel的功能 refactor: 把支付模块的重复校验逻辑抽成公共方法如果已经提交了一堆零碎的记录怎么办用交互式rebase来整理git rebase -i HEAD~5这会打开编辑器列出最近5次提交。你可以把pick改成squash来合并提交改成reword来修改提交信息或者调整行的顺序来重排提交。这个操作在提PR之前做一次能让review的人舒服很多。注意已经推送到远程分支的提交如果别人可能已经拉取过就不要再用rebase改写了。改写公共历史是团队协作的大忌会导致别人的本地分支和远程对不上。3.2 分支合并merge还是rebase这是面试出现频率最高的问题之一也是实际工作中争议最大的话题。merge的做法是创建一个新的合并提交把两个分支的历史连接起来。好处是保留了完整的分支拓扑结构能看出这里曾经有一个分支被合进来了。坏处是如果分支很多提交图会变得非常复杂。rebase的做法是把当前分支的提交一个个摘下来重新应用到目标分支的最新提交之上。好处是历史变成一条直线非常干净。坏处是原始的分支信息丢失了而且如果处理不当容易出问题。我的实际经验是本地分支同步远程主分支的更新时用rebase功能分支合入主分支时用merge。具体来说# 在feature分支上同步main的最新改动 git checkout feature git rebase main # 功能开发完成后合入main git checkout main git merge --no-ff feature--no-ff的意思是强制创建一个合并提交即使可以快进合并也这么做。这样在历史里能清楚地看到这个功能是通过一个分支合进来的方便日后回溯。3.3 冲突处理的正确姿势冲突不可怕可怕的是不知道怎么处理。当两个分支修改了同一个文件的同一区域时Git没法自动决定保留哪个就会产生冲突。冲突文件里会出现这样的标记 HEAD 你当前分支的代码 要合并进来的分支的代码 feature-branch处理流程是手动编辑文件决定最终保留什么内容删掉那些、、标记然后git add标记为已解决最后git commit完成合并。Mac上我推荐用VS Code来处理冲突它会在冲突区域上方显示Accept Current ChangeAccept Incoming ChangeAccept Both Changes几个按钮点一下就能快速选择比手动删标记快得多。有个技巧很多人不知道配置git mergetool可以用图形化工具处理冲突。但说实话大部分冲突用编辑器手动改就够了没必要上图形工具。一个容易忽略的点冲突解决完之后一定要实际跑一下代码确认没问题再提交。我见过有人解决冲突时把两边的代码都保留了结果语法都通不过。4. 那些让面试官眼前一亮的进阶操作4.1 reset的三种模式到底有什么区别git reset是面试高频考点三种模式的区别必须搞清楚模式移动HEAD重置暂存区重置工作区典型用途--soft是否否撤销commit但保留改动在暂存区--mixed默认是是否撤销commit和add改动留在工作区--hard是是是彻底丢弃所有改动记忆方法soft最温柔只动HEADmixed中等动HEAD和暂存区hard最狠三个区域全重置。实际工作中--hard要慎用因为它会永久丢弃工作区的改动。如果不小心reset --hard了可以用git reflog找到之前的提交哈希然后git reset --hard hash恢复回来。reflog记录了HEAD的所有移动历史是Git的后悔药。4.2 cherry-pick精准摘取某个提交场景你在feature分支上修了一个bug但main分支也需要这个修复而feature分支还有其他没完成的改动不能整体合并。这时候cherry-pick就派上用场了git checkout main git cherry-pick commit-hash它会把指定的那个提交复制到当前分支上生成一个新的提交哈希不同但内容相同。cherry-pick在热修复场景下特别有用。比如线上出了紧急bug你在hotfix分支修好之后需要把这个修复同步到develop分支就可以用cherry-pick精准摘取而不用把整个hotfix分支合过去。4.3 stash临时保存工作现场正在写代码写到一半突然要切分支去处理一个紧急问题但当前改动又不想提交。这时候用stashgit stash push -m 登录模块重构到一半 git checkout hotfix # 处理完紧急问题后 git checkout feature git stash popstash pop会恢复最近一次stash并把它从栈里删除stash apply则只恢复不删除。如果stash了多次用git stash list查看用git stash pop stash{2}指定恢复哪一次。有个坑要注意stash默认不会保存未跟踪的文件untracked files。如果你新建了文件但还没git addstash之后这些文件会留在工作区。要连未跟踪文件一起stash得加-u参数git stash push -u -m 包含新文件的临时保存4.4 reflogGit的时光机reflog是我认为最被低估的Git功能。它记录了HEAD和分支引用的每一次移动包括commit、reset、rebase、merge等所有操作。当你误删了分支、reset错了提交、rebase搞砸了reflog几乎总能救你回来。git reflog # 输出类似 # a1b2c3d HEAD{0}: reset: moving to HEAD~3 # e4f5g6h HEAD{1}: commit: 新增支付回调处理 # i7j8k9l HEAD{2}: commit: 修复订单金额计算错误找到你想回到的那个提交哈希然后git reset --hard hash或者git checkout hash就能恢复。注意reflog默认只保留90天不可达对象30天而且只在本地有效不会推送到远程。所以它救不了远程分支被强推覆盖这种情况。5. Mac环境下特有的注意事项5.1 文件名大小写问题Mac的默认文件系统APFS是大小写不敏感的但Git是大小写敏感的。这意味着你把Readme.md改成readme.mdMac的文件系统认为没变化但Git可能认为变了也可能认为没变行为很不一致。解决办法是告诉Git忽略大小写变化git config --global core.ignorecase true但更好的做法是重命名时用两步操作git mv Readme.md temp.md git mv temp.md readme.md这样Git能明确感知到重命名操作。5.2 凭证管理Mac上Git推送时每次都要输密码很烦。可以用osxkeychain来缓存凭证git config --global credential.helper osxkeychain这样第一次输入凭证之后后续就会自动从钥匙串里读取。如果换了账号或者凭证失效了需要去钥匙串访问里删掉对应的条目。5.3 .DS_Store文件Mac的Finder会在每个目录下生成.DS_Store文件用来记录图标位置等元信息。这些文件不应该提交到仓库里。在项目根目录的.gitignore里加上.DS_Store **/.DS_Store如果已经不小心提交了需要从Git的跟踪中移除git rm --cached .DS_Store--cached的意思是只从Git的索引里删除保留本地文件。6. 面试高频问题拆解与回答思路6.1 说说你对Git工作流程的理解这个问题的回答框架可以是先讲三个区域工作区、暂存区、版本库的模型再讲文件在这三个区域之间的流转最后结合实际开发流程说明——从拉取远程代码、创建功能分支、开发提交、推送到远程、发起合并请求的完整链路。关键是要让面试官感觉到你理解的是模型而不是命令。命令会过时模型不会。6.2 merge和rebase的区别你什么时候用哪个前面已经详细讲过回答时要点出核心区别merge保留分支拓扑但历史复杂rebase历史线性但丢失分支信息。然后给出你的实际使用策略——本地同步用rebase保持整洁功能合入用merge保留上下文。如果能补充一句已经推送到远程的公共分支不要rebase会让面试官觉得你有团队协作意识。6.3 代码提交后发现有bug怎么处理分情况讨论如果还没推送到远程git commit --amend修改最后一次提交或者用交互式rebase修改更早的提交。如果已经推送但只有自己用这个分支可以git push --force-with-lease强推覆盖注意用--force-with-lease而不是--force前者会在远程有新提交时拒绝推送更安全。如果已经合入主分支不要改写历史直接创建一个新的修复提交用git revert或者直接改代码再提交。6.4 git pull和git fetch的区别fetch只是把远程的最新内容下载到本地的远程跟踪分支比如origin/main不会动你的工作区。pull等于fetch加merge或者rebase取决于配置。我个人的习惯是先用fetch看看远程有什么变化确认没问题再手动merge或rebase。这样比直接pull更可控避免自动合并产生意外的冲突。7. 一套可以直接抄的Git工作流配置7.1 全局配置清单# 基础身份 git config --global user.name 你的名字 git config --global user.email 你的邮箱 # 换行符处理Mac用户 git config --global core.autocrlf input # 大小写不敏感Mac用户 git config --global core.ignorecase true # 凭证缓存 git config --global credential.helper osxkeychain # 默认分支名 git config --global init.defaultBranch main # 推送时只推当前分支 git config --global push.default current # 拉取时用rebase而不是merge git config --global pull.rebase true # 好看的日志 git config --global alias.lg log --graph --prettyformat:%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%an%Creset --abbrev-commit # 查看最近一次提交的改动 git config --global alias.last show --stat HEAD # 撤销最近一次提交但保留改动 git config --global alias.undo reset --soft HEAD~17.2 日常开发的标准流程# 1. 同步主分支 git checkout main git pull # 2. 创建功能分支 git checkout -b feature/xxx # 3. 开发过程中频繁提交 git add -p # 交互式选择要暂存的改动块 git commit -m feat: 完成xxx功能 # 4. 同步主分支最新改动在feature分支上 git fetch origin git rebase origin/main # 5. 推送到远程 git push -u origin feature/xxx # 6. 发起合并请求等待review # 7. 合并后清理本地分支 git checkout main git pull git branch -d feature/xxxgit add -p这个命令值得单独说一下。它会把你文件里的改动拆成一个个块hunk逐个问你要不要暂存。这样你可以把不相关的改动分开提交保持每次提交的原子性。虽然多花几秒钟但提交历史会干净很多。7.3 .gitignore的写法要点# 忽略所有.DS_Store .DS_Store # 忽略node_modules node_modules/ # 忽略构建产物 dist/ build/ *.o *.class # 忽略IDE配置 .idea/ .vscode/ *.swp # 忽略环境变量文件 .env .env.local # 但保留模板文件 !.env.example!开头的规则表示不忽略用来在忽略整个目录后重新包含某些文件。这个技巧在忽略所有配置文件但保留模板的场景下很有用。8. 我踩过的那些坑和总结出的经验说几个我实际踩过的坑都是文档里不会写的。第一个坑git checkout的歧义。当你有一个分支叫feature同时有一个文件也叫feature时git checkout feature会报错Git不知道你指的是分支还是文件。解决办法是用git checkout -- feature明确表示文件或者用git switch featureGit 2.23之后的新命令明确表示分支。我现在已经全面改用git switch和git restore了语义更清晰不容易出错。第二个坑rebase时误删提交。交互式rebase的编辑器里如果你不小心把某一行删掉了那个提交就真的没了。虽然可以用reflog找回来但当时会吓出一身冷汗。我的经验是rebase之前先git branch backup创建一个备份分支搞砸了随时能回来。第三个坑.gitignore对已跟踪文件无效。很多人以为把文件加到.gitignore里就完事了但如果这个文件已经被Git跟踪了.gitignore是不起作用的。必须先用git rm --cached把它从跟踪中移除.gitignore才会生效。第四个坑Mac上文件名大小写导致的问题。前面提过这里再强调一次。团队里如果有Linux和Mac混用的情况文件名大小写不一致会导致各种诡异问题。最好的办法是团队约定文件名全部用小写加连字符比如user-service.js而不是UserService.js。第五个坑git push --force覆盖别人的提交。这个坑的严重程度取决于团队规模。小团队可能只是被骂一顿大团队可能直接导致别人的工作丢失。永远用--force-with-lease代替--force它会在推送前检查远程分支是否比你本地的更新如果有别人的提交就拒绝推送。最后分享一个我用了很久的习惯每次开始写代码之前先git status确认当前状态是干净的然后git pull同步最新代码。这个习惯看起来简单但能避免80%的为什么我的代码跟别人不一样的问题。写代码之前花十秒钟确认状态比事后花半小时排查冲突划算得多。