1. Git 面试题深度解析从基础操作到高阶技巧作为分布式版本控制系统的行业标准Git 在技术面试中的考察频率居高不下。最近帮团队面试了几位候选人发现很多开发者对git pull、rebase、squash这些基础操作的理解仍停留在表面。今天我就结合 7 年团队协作经验拆解这些高频面试题背后的核心逻辑和实战场景。2. 基础操作pull vs fetch 的生死抉择2.1 git pull 的双重身份执行git pull时实际发生了两件事git fetch下载远程最新提交git merge将远程分支合并到当前分支典型问题为什么我的 pull 操作总会产生 merge commit 答案就在这个默认行为里。在团队协作中这可能导致提交历史出现大量无意义的合并节点。关键技巧使用git pull --rebase可以避免自动生成 merge commit保持线性历史2.2 fetch 的侦察兵作用与 pull 不同git fetch只执行数据下载不自动合并。这就像先派侦察兵了解敌情再决定作战方案。实际开发中建议频繁使用 fetch 监控远程变化明确需要合并时再手动执行 merge/rebase配合git log origin/main..main查看本地与远程差异3. 合并策略merge 与 rebase 的哲学之争3.1 merge 的保守主义标准的三方合并会产生新的合并节点保留完整历史轨迹。适合公共分支如 main/dev的集成需要明确记录合并时间的场景跨团队协作时保持历史可追溯性# 典型merge操作 git checkout feature git merge main # 将main分支合并到feature3.2 rebase 的激进美学通过变基重写提交历史创造完美的线性提交链。注意绝对不要在公共分支上 rebase适合本地特性分支同步主分支更新会产生新的 commit hash 可能影响协作# rebase标准流程 git checkout feature git rebase main # 将feature分支变基到main血泪教训曾经有同事在共享分支执行 rebase导致全团队需要 reset --hard。记住黄金法则——只对本地未推送的提交做 rebase。4. 高阶技巧squash 与 cherry-pick 的精准手术4.1 squash 的提交美容将多个琐碎提交压缩为单个有意义的提交# 交互式rebase压缩提交 git rebase -i HEAD~3 # 合并最近3个提交在 PR/MR 工作流中特别有用可以清理 fix typo 之类的琐碎提交保持主分支历史清晰配合 GitHub/GitLab 的 squash merge 功能使用4.2 cherry-pick 的移植术精准复制特定提交到当前分支git cherry-pick abc123 # 应用指定commit典型使用场景将热修复提交应用到多个发布分支从错误分支抢救特定修改避免全量合并带来的不必要变更5. 面试高频问题实战解析5.1 冲突解决全流程当合并/变基出现冲突时暂停操作merge/rebase 会提示冲突使用git status查看冲突文件手动编辑文件解决冲突搜索标记git add标记已解决文件继续操作git rebase --continue或直接提交5.2 后悔药大全撤销未提交的修改git checkout -- file重置暂存区git reset HEAD file回退到某个提交git reset --hard abc123恢复误删分支git reflog配合git checkout -b branch hash6. 企业级 Git 工作流建议6.1 分支管理策略功能开发feature/前缀 JIRA 编号如 feature/PROJ-123热修复hotfix/ 前缀 问题描述发布分支release/ 版本号主分支保护设置 Code Owner 和 PR 审核6.2 提交信息规范采用语义化提交格式feat: 添加用户登录功能 fix: 修复密码强度校验漏洞 chore: 更新依赖包版本 docs: 补充API接口文档7. 进阶工具链推荐7.1 可视化工具GitLensVSCode 插件查看代码作者和修改历史Sourcetree图形化操作复杂流程tig终端下的交互式浏览工具7.2 配置优化[alias] lol log --graph --decorate --oneline st status -sb cm commit -m [core] autocrlf input # 跨平台换行符处理在面试中遇到 Git 问题时建议先明确面试官想考察的维度是基础操作熟练度对分布式原理的理解还是团队协作经验根据不同的侧重点组织答案比死记硬背命令更有效果。