本文面向前端面试场景，覆盖从日常开发高频命令，到面试官必问的核心原理辨析，所有内容均来自面试实战考点，无冗余废话，面试前刷一遍直接通关。
开篇前言
Git 是前端开发的必备工具，也是几乎所有公司一面必问的基础考点。但很多同学日常开发只会用add/commit/push/pull，一被问到merge和rebase的区别、代码回滚方案、分支管理规范就卡壳。
本文基于我备战前端实习的面试笔记整理，先补全优化前端开发必背的全量高频命令，再深度拆解面试最高频的merge vs rebase考点，最后补充面试常问的附加题，帮大家彻底搞定 Git 面试。
一、前端开发 & 面试必背 Git 常用命令大全
我将所有命令按开发场景做了模块拆分，保留了基础核心用法，同时补全了面试常考的进阶参数和注意事项，可直接当作面试速查手册。
1. 仓库初始化与远程关联
表格
| 命令 | 核心作用 | 面试注意事项 |
|---|---|---|
git init | 在当前目录初始化一个全新的 Git 本地仓库 | 初始化后会生成.git隐藏目录，存储 Git 所有的版本和配置信息 |
git clone <远程仓库地址> | 克隆远程仓库到本地，自动完成远程关联 | 面试常考：支持 HTTPS 和 SSH 两种地址，SSH 需提前配置密钥 |
git remote add origin <远程仓库地址> | 给本地仓库关联远程仓库，origin 是远程仓库的默认别名 | 必用场景：本地 init 的仓库首次推送到远程前，必须先执行此命令 |
git remote -v | 查看当前仓库关联的远程仓库地址详情 | 排查远程仓库配置问题的核心命令 |
2. 分支管理核心命令（面试超高频）
表格
| 命令 | 核心作用 | 面试注意事项 |
|---|---|---|
git branch | 查看所有本地分支，带*的是当前所在分支 | 基础必背，面试官常以此为起点延伸分支相关问题 |
git branch -r | 查看所有远程分支 | |
git branch -a | 查看所有分支（本地 + 远程） | |
git checkout <分支名> | 切换到已存在的本地分支 | 高频快捷操作：git checkout - 一键切换到上一个分支 |
git checkout -b <新分支名> | 创建并立即切换到新分支 | 等价于git branch <新分支名> + git checkout <新分支名>，开发最高频用法 |
git checkout -b <新分支名> <起点> | 基于指定起点（远程分支 / 历史提交 / 标签）创建新分支 | 示例：git checkout -b hotfix/v1.0 origin/main，面试常考场景化用法 |
git branch -d <分支名> | 安全删除本地分支 | 仅能删除已经合并到当前分支的分支，未合并的分支会报错，防止误删代码 |
git branch -D <分支名> | 强制删除本地分支 | 无论分支是否合并，都会直接删除，仅用于废弃的功能分支，面试常问-d和-D的区别 |
git push origin --delete <远程分支名> | 删除远程分支 |
补充：Git 2.23+ 官方推出语义更清晰的
git switch替代checkout的分支操作功能，面试可提：
- 切换分支：
git switch <分支名>- 创建并切换新分支：
git switch -c <新分支名>解决了checkout功能过载、容易误操作的问题。
3. 代码提交与暂存核心命令
表格
| 命令 | 核心作用 | 面试注意事项 |
|---|---|---|
git status | 查看当前工作目录和暂存区的状态，显示未跟踪、已修改、已暂存的文件 | 开发必用，切换分支、提交代码前建议必执行，避免误操作 |
git add <文件路径/文件名> | 将指定文件的修改 / 新增添加到暂存区 | |
git add . | 将当前目录所有修改、新增的文件添加到暂存区 | 面试常考：不会处理已删除的文件，仅新增和修改 |
git add -u | 仅将已跟踪文件的修改、删除添加到暂存区，不包含新增文件 | 高频场景：只想提交已有文件的改动，不想提交新增的临时文件 |
git commit -m "提交描述信息" | 将暂存区的内容提交到本地仓库，生成一条提交记录 | 核心要求：提交信息必须语义化，面试常问提交规范 |
git commit -am "提交描述信息" | 等价于git add -u + git commit -m，一步完成已跟踪文件的提交 | 注意：对新增的未跟踪文件无效 |
git commit --amend | 修改上一次的提交信息，或补充漏提交的文件，不会生成新的提交 | 面试高频考点：仅适用于未推送到远程的本地提交，已推送的提交修改后会重写历史，需要强制推送，有极高风险 |
4. 代码拉取与推送核心命令
表格
| 命令 | 核心作用 | 面试注意事项 |
|---|---|---|
git push | 将本地当前分支的提交推送到已关联的远程分支 | 首次推送必须加-u参数设置上游分支：git push -u origin <分支名>，后续可直接用git push |
git push -f | 强制推送本地分支覆盖远程分支 | 高危操作！仅能在自己的私有分支使用，绝对禁止在公共分支执行，会直接覆盖远程历史，导致团队代码丢失 |
git pull | 拉取远程当前分支的最新代码，并自动合并到本地分支 | 面试核心考点：git pull = git fetch + git merge，默认用 merge 方式合并，会生成合并提交 |
git pull --rebase | 拉取远程最新代码，并用 rebase 方式合并到本地分支 | 多人协作高频用法，避免生成多余的合并提交，保持本地历史线性 |
git fetch | 仅拉取远程仓库的所有最新提交到本地，不会自动合并 | 面试常问和git pull的区别：更安全，可先查看远程改动，再手动决定是否合并，不会直接修改本地工作区 |
5. 临时存储 stash 全命令（面试高频）
表格
| 命令 | 核心作用 | 面试注意事项 |
|---|---|---|
git stash | 将当前分支未提交的改动（工作区 + 暂存区）临时保存到堆栈中，清空工作区 | 高频场景：正在开发功能，突然需要切换分支改 bug，又不想提交半成品代码 |
git stash save "存储备注信息" | 给 stash 记录添加备注，方便后续识别 | 多个 stash 记录时必用，避免分不清存储的内容 |
git stash list | 查看堆栈中所有的 stash 存储记录 | |
git stash pop | 恢复堆栈中最新的一条 stash 记录，并删除该条记录 | 恢复后会自动从堆栈中移除，对应git stash的反向操作 |
git stash apply | 恢复最新的 stash 记录，但不会从堆栈中删除 | 场景：需要把同一份改动恢复到多个分支 |
git stash drop | 删除堆栈中最新的一条 stash 记录 | |
git stash clear | 清空堆栈中所有的 stash 记录 |
6. 提交历史查看命令
表格
| 命令 | 核心作用 | 面试注意事项 |
|---|---|---|
git log | 查看当前分支的完整提交日志记录，包含提交哈希、作者、时间、提交信息 | |
git log --oneline | 一行显示一条提交记录，仅展示简短提交哈希和提交信息 | 高频用法，快速查看提交历史，面试必提 |
git log --graph | 图形化展示分支的合并历史和分叉情况 | 配合--oneline使用效果极佳，直观看到分支合并轨迹 |
git log -p | 查看提交日志的同时，显示每次提交的具体代码改动内容 | 排查问题、代码溯源高频用法 |
7. 工作区修改撤销与文件恢复
表格
| 命令 | 核心作用 | 面试注意事项 |
|---|---|---|
git checkout -- <文件路径/文件名> | 用暂存区的版本覆盖工作区的文件，撤销未暂存的修改 | ⚠️ 高危操作：修改不可逆，本地未暂存的改动会永久丢失 |
git checkout -- . | 撤销当前目录所有未暂存的修改 | |
git checkout <提交哈希/分支名> -- <文件路径> | 用指定提交 / 分支的文件版本，覆盖当前工作区和暂存区的对应文件 | 场景：恢复某个文件到历史版本，不影响其他文件 |
补充：Git 2.23+ 官方推出
git restore替代checkout的文件恢复功能，语义更清晰：
- 撤销工作区未暂存修改：
git restore <文件名>- 撤销暂存区的修改：
git restore --staged <文件名>
二、前端面试最高频考点：git merge vs git rebase 深度辨析
这是 Git 面试的必问题，90% 的面试官都会问到，很多同学只能答出 “一个会生成合并提交，一个不会”，但想要拿到高分，必须从原理、区别、优缺点、场景、禁忌全维度讲透。
1. 核心相同点
git merge和git rebase的核心目标完全一致：将一个分支的代码变更，整合到另一个分支中，是 Git 中最核心的两种分支合并方案。
2. 核心原理（面试答题先讲原理，直接拉开差距）
我们用一个最常见的开发场景举例：
主分支
main有提交记录A→B→C，我们从C切出功能分支feature开发，提交了D→E；此时main分支有了新的提交F→G，现在需要把main的最新代码合并到feature，或者把feature合并到main。
git merge 原理
git merge采用三方合并策略，执行git merge feature时会做 3 件事：
- 找到两个分支的最近共同祖先 C；
- 基于共同祖先，将两个分支的变更做三方合并对比；
- 最终生成一个全新的合并提交 H，这个提交有两个父提交，分别指向两个分支的最新提交
G和E，同时完整保留两个分支的所有原始提交历史。
最终合并后的main分支历史：A→B→C→F→G→H(合并提交)，feature分支的D、E提交完整保留，时间线是分叉的。
git rebase 原理
rebase直译是变基，核心是改变分支的基准，执行git rebase main时会做 4 件事：
- 找到两个分支的最近共同祖先 C；
- 提取
feature分支上从C之后的所有提交D、E，临时保存起来； - 将
feature分支的基准指针，直接指向main分支的最新提交G； - 按顺序将临时保存的
D、E，逐个重放应用到新的基准G上，生成新的提交D'、E'。
最终变基后的feature分支历史：A→B→C→F→G→D'→E'，形成了完全线性的提交记录，没有任何合并提交，原始的D、E提交会被废弃，提交历史被重写。
3. 全维度对比表（面试分点答，逻辑拉满）
表格
| 对比维度 | git merge | git rebase |
|---|---|---|
| 核心逻辑 | 三方合并，生成全新的合并提交 | 变基重放，逐个应用提交，重写提交历史 |
| 提交历史 | 完整保留所有分支的原始提交，时间线分叉，上下文完整 | 重写提交历史，形成线性记录，无多余合并提交，原始上下文丢失 |
| 冲突处理 | 合并时仅需解决 1 次冲突，解决后生成合并提交即可，成本极低 | 变基过程中，每个提交重放时都可能产生冲突，需要逐个解决，提交越多成本越高 |
| 操作安全性 | 极高，不会修改现有提交历史，所有操作都有记录可追溯，不会丢失代码 | 高危，会重写提交历史，操作失误极易丢失提交，可通过git reflog恢复，但有门槛 |
| 代码溯源 | 完整的合并轨迹，可精准定位 bug 是哪个分支、哪次提交引入的，排查问题效率高 | 提交历史被重写，原始提交的上下文丢失，问题溯源难度大幅提升 |
| 公共分支兼容性 | 完全兼容，是公共分支合并的标准方案 | 绝对禁止在公共分支使用，会导致团队成员分支历史不一致，引发灾难性冲突 |
4. 优缺点详解
git merge 优缺点
✅ 优点：
- 操作简单、上手门槛低，符合 Git 分布式设计的初衷，全程安全无风险；
- 完整保留所有分支的开发上下文和提交历史，方便后续代码审计、问题回溯、版本回滚；
- 冲突处理简单，仅需解决一次冲突，不会出现重复处理冲突的情况；
- 支持快进合并（Fast-Forward），当目标分支无新提交时，可直接移动分支指针，无需生成合并提交。
❌ 缺点：
- 多人协作频繁合并时，会产生大量的合并提交，导致提交历史分叉严重，可读性变差；
- 对于追求简洁线性提交历史的团队，多余的合并提交会显得冗余，不利于版本管理。
git rebase 优缺点
✅ 优点：
- 最终会形成干净、无分叉的线性提交历史，提交日志可读性极强，方便版本迭代回溯；
- 支持交互式变基
git rebase -i，可在合并前整理本地提交（合并零散提交、修改提交信息、删除无用提交），让提交记录更规范； - 用
git pull --rebase拉取远程代码，可避免生成多余的合并提交，保持本地分支的线性历史。
❌ 缺点：
- 操作风险高，重写提交历史的操作不可逆，一旦失误极易丢失代码；
- 冲突处理成本高，多个提交重放时需要逐个解决冲突，重复操作多；
- 重写历史后，原始提交的上下文丢失，出现问题时很难精准定位 bug 引入的节点；
- 在公共分支使用会给团队带来灾难性后果，所有成员都需要强制同步重写后的历史，极易出现代码丢失、冲突爆炸。
5. 最佳实践 & 使用场景（面试必答，体现你的实战经验）
git merge 推荐使用场景
- 将功能分支合并到公共主分支（main/master、develop）时，必须使用 git merge，建议搭配
--no-ff参数（禁用快进合并），强制生成合并提交，完整保留分支合并的上下文，方便后续追溯和回滚； - 多人协作的公共分支之间的合并，保证所有团队成员的提交历史一致，不会出现历史混乱；
- 合并到上线分支、生产分支时，必须使用 merge，保证所有操作可追溯，出问题可快速回滚；
- 需要完整保留分支开发上下文，用于代码审计、合规检查的场景。
git rebase 推荐使用场景
- 本地私有功能分支的提交历史整理，比如自己开发的 feature 分支，在合并到公共分支之前，用
git rebase -i HEAD~n整理零散的提交，让提交记录语义化、规范化； - 本地分支拉取远程公共分支的最新代码时，用
git pull --rebase代替默认的git pull，避免生成多余的合并提交，保持本地分支的线性历史； - 给开源项目提交 PR/MR 时，绝大多数开源项目要求提交历史是线性的，需要用 rebase 基于上游最新分支整理提交，避免合并冲突和冗余的合并提交；
- 个人独立开发的项目，想要保持干净的线性提交历史，可自由使用 rebase。
6. 黄金法则（面试答出来直接加分）
永远不要在已经推送到远程的公共分支上，执行 git rebase 操作！
公共分支是所有团队成员的开发基准，你 rebase 之后会重写公共分支的提交历史，其他成员的本地分支还是基于原来的历史，当他们拉取代码时，会出现两个版本的历史，合并后会产生大量重复的提交和无法解决的冲突，最终导致代码仓库的历史彻底混乱，甚至丢失核心代码。
三、前端面试 Git 高频附加题
除了核心的 merge/rebase，这些考点也是面试官常问的，补充在这里帮大家全面通关：
1. git reset 和 git revert 的区别？
核心区别：是否重写提交历史，是否可逆
git revert：生成一个新的提交，反向撤销目标提交的所有改动，不会修改现有提交历史，安全，适合公共分支的代码回滚，所有操作可追溯；git reset：直接移动分支指针，删除目标提交之后的所有提交，会重写提交历史，分为--soft（保留改动到暂存区）、--mixed（默认，保留改动到工作区）、--hard（彻底丢弃所有改动，高危），仅适合本地私有分支的回滚，绝对禁止在已推送的公共分支使用。
2. 什么是分离头指针（detached HEAD）？有什么风险？
- 定义：执行
git checkout <提交哈希/标签名>时，HEAD 指针不再指向任何一个命名分支，而是直接指向一个具体的提交记录，此时就进入了分离头指针状态； - 风险：此状态下的提交，属于匿名分支上的提交，一旦切换到其他分支，这些提交会被 Git 的垃圾回收机制清理，极易丢失；
- 解决方案：如果需要在此状态下保留修改，立即执行
git checkout -b <新分支名>，创建新分支保存这些提交。
3. .gitignore 文件不生效怎么办？
-
根本原因：
.gitignore只能忽略未被跟踪的文件，如果文件已经被提交到 Git 仓库，就不会被 ignore 规则匹配； -
解决方案：
- 先把本地需要忽略的文件备份，避免丢失；
- 执行
git rm -r --cached .，清除所有文件的本地跟踪缓存； - 重新执行
git add .，此时.gitignore规则会生效，忽略指定文件； - 提交修改到仓库即可。
4. 不小心把账号密码、密钥等敏感信息提交到 Git 仓库了，怎么办？
-
第一步：立即修改敏感信息的密码 / 密钥，杜绝泄露风险；
-
第二步：清理 Git 仓库中的敏感信息：
- 如果是仅本地提交、未推送到远程：用
git reset --soft HEAD~1回滚提交，修改后重新提交即可； - 如果已经推送到远程公共仓库：用
git filter-repo（官方推荐）或 BFG 工具彻底清理历史记录，清理后需要强制推送重写历史；
- 如果是仅本地提交、未推送到远程：用
-
第三步：如果是开源仓库，建议联系平台仓库管理员，彻底清理缓存记录。
结尾总结
Git 作为前端开发的必备工具，面试考察的核心从来不是你背了多少命令，而是你是否理解每个操作背后的原理，是否知道不同操作的风险和最佳实践。
核心记住两点：
- 公共分支永远用
merge，保证安全和可追溯；私有分支可以用rebase整理提交历史，保持简洁； - 所有会重写提交历史的操作（
rebase、reset --hard、commit --amend），绝对不要用在已经推送到远程的公共分支上。
这篇文章整理了我备战前端实习面试的 Git 核心笔记，希望能帮到同样在找工作的同学。如果觉得有用，欢迎点赞、收藏、评论，我会持续更新前端面试的干货内容～
