IDEA Git 全套实操练习题（零基础到面试实战）

适用：日常开发、面试机试、团队协作练兵

环境要求：已安装Git、IDEA配置好Git、任意Gitee/GitHub远程仓库（空仓库即可）

做题规则：全程使用IDEA图形化操作，禁止手动敲Git命令，贴合真实开发场景

一、基础入门题（必会）

练习题1：本地项目初始化Git仓库 + 首次提交

场景

本地新建 Java 项目，项目尚未做任何版本控制，需要将项目纳入 Git 管理，完成第一次本地提交。

前置条件：Git 客户端已安装；IDEA File→Settings→Version Control→Git 点击 Test 测试通过。

✅ 标准答案步骤

1.IDEA 新建空白 Java 项目，在 src 目录下创建Test.java，编写测试代码

public class Test {
public static void main(String[] args) {
System.out.println("Git测试项目");
}
}

2.顶部菜单 VCS → Enable Version Control Integration

• 弹窗下拉框选择 Git，点击 OK。

效果：项目根目录自动生成隐藏文件夹 .git，即本地 Git 仓库；此时文件显示红色，表示 Git 识别到文件，但文件还未加入暂存区，未被追踪。

3.将文件加入暂存区

• 右键Test.java → Git → Add

效果：文件颜色变为绿色，文件从工作区进入暂存区。

4.执行本地 Commit 提交

• 顶部菜单 Git → Commit（快捷键 Ctrl+K）

• Commit message 填写：feat: 项目初始化

• 下方勾选待提交文件Test.java

• 练习场景建议：取消勾选Run tests、Run code analysis，提升提交速度

• 点击 Commit

✅ 验证标准（操作完成核对）

📸截图指引

• 截图 1：Enable Version Control Integration弹窗，下拉选中 Git 的界面

• 截图 2：Commit 提交弹窗，展示提交备注、待提交文件列表

• 截图 3：Git Log 面板，展示初始化提交记录

💡 考点 & 易错点（面试高频）

1.Enable Version Control Integration 等价命令：git init，作用：初始化本地 Git 仓库。

2.Add（git add）：文件进入暂存区，仅仅是临时存放，没有生成版本。

3.Commit（git commit）：将暂存区代码提交到本地仓库，仅本地生效，不会自动推送到远程仓库。

坑 1：只 Add 不 Commit，代码停留在暂存区，没有版本记录。

坑 2：未执行git init直接 commit，会报错，提示不是 git 仓库。

坑 3：不要手动修改.git文件夹内文件，会直接损坏本地仓库。

🧪拓展小练习（可选）

修改Test.java内代码，文件变为蓝色（已追踪文件发生改动）；执行 Add，文件变回绿色，再 Commit 生成第二条版本记录，观察 Git 日志新增一条提交。

❓ 常见报错排查

1.找不到 VCS 菜单：IDEA 版本不同，位置略有差异；确认 Git 插件已启用。

2.Add 灰色不可点：当前目录没有初始化 Git 仓库，先执行 Enable Version Control Integration。

3.Commit 按钮灰色：没有勾选待提交文件，或者没有填写 commit 备注。

练习题2：绑定远程仓库 + 推送首次代码

场景

本地项目已经完成 Git 初始化并完成首次 commit，现在需要关联云端空仓库，把本地代码推送到远程仓库。

前置条件：

1.完成练习题 1，本地仓库已有一次提交记录

2.Gitee/GitHub/GitLab 新建空仓库（不要勾选 README、LICENSE、.gitignore，避免初始提交冲突）

3.已经配置好 SSH 密钥（推荐 SSH 方式；也可使用 HTTPS）

✅ 标准答案步骤

1.复制远程仓库地址 进入云端新建仓库页面，复制仓库地址（SSH 优先，HTTPS 备选）。

2.IDEA 添加远程仓库 File → Settings → Version Control → Git Remotes

• 点击右上角加号 +

• Name：默认填写origin（远程仓库别名，约定俗成，不建议修改）

• URL：粘贴刚刚复制的远程仓库地址

• 点击 OK 保存。

等价 Git 命令：git remote add origin xxx.git

3.推送本地分支到远程 顶部菜单 Git → Push（快捷键 Ctrl+Shift+K）

• 弹出 Push 窗口：本地分支main，远程目标分支main

• 确认分支映射关系，点击Push

补充：部分 Git 版本默认主分支名称为master，按需选择对应分支。

✅ 验证标准（操作完成核对）

1.浏览器打开远程仓库页面，刷新，能看到Test.java文件。

2.IDEA 右下角 Git Log 中，提交记录会显示远程分支标记origin/main。

3.再次打开 Git Remotes 设置，可以看到 origin 对应的远程地址。

📸截图指引

截图 1：Git Remotes 配置页面，展示 origin 名称和远程仓库 URL

截图 2：Push 推送弹窗，本地分支映射远程分支

截图 3：浏览器远程仓库页面，成功看到上传的 Test.java

💡 考点 & 易错点（面试高频）

1.origin 只是远程仓库别名，可以自定义，但行业约定统一使用 origin。

2.推送只是将本地仓库的版本上传到远端，不会影响本地代码。

3.SSH 方式：免重复输入账号密码；HTTPS 方式，账号密码会保存在系统凭据管理器。

坑 1：远程仓库新建时勾选了 README，远程存在初始提交，直接 push 会报错rejected，需要先 pull 合并再推送。

坑 2：URL 复制错误（多空格、换行），导致连接远程仓库失败。

坑 3：Git Remotes 配置完成后，Push 弹窗看不到分支：本地没有 commit 提交，没有版本可推送。

🧪拓展小练习（可选）

打开 Git Remotes，尝试修改 origin 仓库地址，切换 SSH/HTTPS 两种地址，观察推送连接方式变化。

❓ 常见报错排查

1.Push rejected：远程仓库存在初始提交（README），本地与远程历史不一致。解决：先Git → Pull拉取远程代码合并，再 Push。

2.无法连接仓库：检查网络；SSH 模式确认密钥已添加到平台；HTTPS 确认账号权限。

3.Remote origin already exists：已经配置过 origin，在 Git Remotes 选中旧 origin，编辑或者删除后重新添加。

二、分支实操题（团队开发核心）

练习题3：创建功能分支、切换分支、合并分支

场景

main 为主稳定分支，不直接在 main 上开发新功能。需要新建独立 feature 分支开发登录功能，开发完成后，将 feature 分支代码合并回 main 主分支。

前置条件：

1.完成练习题 1、练习题 2，本地 main 分支已提交并推送到远程仓库

2.远程仓库 main 分支代码与本地保持同步

✅ 标准答案步骤

1.基于当前 main 分支新建功能分支 IDEA 右下角，点击分支下拉（当前显示main） → New Branch

• Branch name：填写 feature/login

• 勾选：Checkout branch（创建分支后自动切换到新分支，默认勾选）

• 点击Create

等价命令：git checkout -b feature/login

2.在 feature/login 分支开发并提交代码 修改Test.java，新增登录相关方法，示例代码：

public class Test {
public static void main(String[] args) {
System.out.println("Git测试项目");
}
//新增登录方法
public boolean login(String username,String password){
return "admin".equals(username) && "123456".equals(password);
}
}

3.切换回 main 主分支 右下角分支下拉，选择main，完成分支切换。

观察现象：编辑器里代码自动变回切换分支前的版本，看不到 login 登录方法。

4.将 feature/login 分支合并到当前 main 分支 右下角分支下拉，找到feature/login，点击展开菜单，选择 Merge into Current（Current 代表当前 main 分支）

• 若无代码冲突，直接合并成功

• 若出现冲突，进入合并窗口手动处理冲突（参考练习题 6 冲突处理逻辑）

5.推送合并后的 main 分支到远程仓库 快捷键 Ctrl+Shift+K 打开 Push 窗口，推送 main 分支到远程 origin/main

✅ 验证标准（操作完成核对）

1.切换 main 分支，Test.java中能看到 login 登录方法，合并生效。

2.Git Log 面板，可以看到一条 Merge 合并提交记录，同时关联 main、feature/login 两个分支。

3.远程仓库 main 分支刷新，代码同步更新。

📸截图指引

截图 1：右下角分支下拉框，New Branch 新建分支弹窗

截图 2：选中 feature/login 分支，Merge into Current菜单界面

截图 3：Git Log 日志，展示 merge 合并提交记录

💡 考点 & 易错点（面试高频）

1.分支本质：Git 分支只是一个提交指针，新建分支不会复制完整代码副本，轻量高效。

2.Merge：将其他分支的代码合并进当前所在分支，会生成一条新的 merge 提交记录，保留完整分支开发历史。

3.工作规范：main/dev 公共分支只用于合并，不直接在上面写业务代码，所有新功能都在 feature 分支开发。

坑 1：新建分支前，本地 main 分支代码没有拉到最新，后续合并容易出现大量冲突。

坑 2：合并分支时，一定要看清楚当前在哪条分支；Merge into Current，是把别的分支合并到【当前分支】，方向不能搞反。

坑 3：合并完成后，feature/login 分支还会保留，需要手动删除（不再使用时）。

🧪拓展小练习（可选）

合并完成后，在右下角分支列表，选中feature/login执行 Delete，删除本地无用功能分支。

❓ 常见报错排查

1.Merge 合并提示冲突：两个分支修改了同一文件同一行，打开 Merge 窗口手动取舍代码。

2.切换分支报错：当前工作区存在未 add、未 commit 的修改，IDEA 不允许切换；要么 commit，要么 stash 储藏代码。

3.Push 推送失败：远程 main 有其他人新提交，先执行 Git → Pull 拉取远程更新，再合并推送。

练习题4：分支变基 Rebase（面试重点）

场景

你在私有功能分支feature/login上开发登录功能；与此同时，main主分支有新提交（模拟团队其他开发者更新 main 分支代码）。

需要将 main 分支最新代码同步到 feature 分支，整理提交历史，让提交记录形成一条干净直线，使用 Rebase 变基操作。

前置条件：

1.已完成练习题 3，仓库存在main、feature/login两条分支

2.重要约束：Rebase只适用于个人私有 feature 分支；多人共享的公共分支 main/dev 禁止执行 rebase

✅ 标准答案步骤

1.切换到 main 分支，模拟同事提交代码 IDEA 右下角分支下拉，切换至main 修改Test.java，新增一行代码：

System.out.println("main分支新增日志输出");

2.快捷键Ctrl+K打开提交窗口，提交备注：fix: main分支新增日志打印Ctrl+Shift+K推送本次提交到远程 main 分支。

3.切回个人功能分支 feature/login 右下角分支下拉，选中feature/login完成切换。

现状：feature/login 上的提交，是基于旧版本 main；main 分支已经新增了一条提交，两个分支出现分叉。

4.执行 Rebase onto（变基到 main 分支） 右下角分支下拉，选中main，点击菜单选择 Rebase onto

等价 Git 命令：git rebase main 原理：将 feature/login 分支上属于自己的提交临时摘下来，放到 main 分支最新提交节点之后，重新生成提交记录，重写分支历史。

5.处理变基冲突（模拟真实开发场景）

• 如果修改了同一行代码，会触发冲突，弹出 IDEA 合并窗口

• 选择 Merge 手动合并代码，保留需要的逻辑，Apply 保存合并结果

• 冲突解决完成后，IDEA 界面点击 Continue Rebase，继续后续提交的变基

• 如果想要放弃本次变基、恢复到操作前状态，点击 Abort Rebase

6.变基完成后推送 feature/login 分支

⚠️关键提醒：若 feature/login 之前已经推送到远程，rebase 改写了提交历史，推送需要使用Push –force-with-lease；

公共分支绝对不能强制推送 顶部菜单Git → Push，出现历史版本冲突提示时，选择force-with-lease（仅私有分支使用）

✅ 验证标准（操作完成核对）

1.打开 Git Log 面板，观察提交图：feature/login 提交接续在 main 最新提交后面，是一条直线，不存在 merge 分叉节点。

2.Test.java文件同时包含 main 新增日志代码 + feature/login 的 login 登录方法。

3.分支指针 feature/login 指向变基后新生成的提交节点。

📸截图指引

截图 1：右下角分支菜单，Rebase onto选项界面

截图 2：变基冲突页面，展示 Continue Rebase / Abort Rebase 操作按钮

截图 3：Git Log 面板，变基完成后的线性提交日志

💡 考点 & 易错点（面试高频）

1.Rebase 本质：移动提交、重写提交历史，不是简单合并代码。

2.Merge 和 Rebase 对比

• Merge：新增独立合并提交，保留分支分叉历史，日志图有分叉，适合公共主分支 main/dev

• Rebase：重写提交记录，提交线干净线性，仅限个人私有 feature 分支

3.致命禁忌：多人共用公共分支执行 rebase，再强制 push，会篡改远程历史，覆盖团队其他成员提交。

坑 1：变基中途遇到冲突，处理完代码后忘记点击Continue Rebase，变基卡在中间状态，分支处于 rebase 进行中。

坑 2：变基前工作区存在未 commit、未 stash 的修改，直接执行 rebase 会报错，需要先 commit 或者 stash。

坑 3：git rebase会重新生成 commit id，原来旧的提交记录 id 失效。

🧪拓展小练习（可选）

1.人为制造代码冲突，练习Abort Rebase，放弃本次变基，观察代码恢复到 rebase 之前的状态。

2.对比练习题 3 的 Merge 日志和本题 Rebase 日志，直观感受两种合并方式图形差异。

❓ 常见报错排查

1.Rebase 提示：工作区存在未提交修改 → 先执行 Stash 储藏代码，再重新执行 rebase。

2.Rebase 冲突处理完成，不知道下一步操作 → 手动 Merge 解决冲突 → Add 标记冲突文件 → 点击 Continue Rebase。

3.Push 被 rejected，rebase 后的私有分支推送 → 使用force-with-lease，不推荐简单–force，force-with-lease 会检查远程分支是否被别人更新，更安全。

三、Stash储藏实操（高频开发场景）

练习题5：代码中途搁置 + 分支切换（Stash核心用法）

场景

正在feature/login分支开发功能，代码写到一半，逻辑不完整，不能提交 commit。此时线上 main 分支出现紧急 bug，需要立刻切换到 main 分支修复问题。直接切换分支会携带当前半成品代码，因此使用 Stash 将未完成代码临时储藏，清空工作区，切换分支处理 bug，处理完毕切回功能分支恢复储藏代码。

前置条件：

1.完成练习题 1~4，仓库存在main、feature/login分支

2.当前处于feature/login分支，准备编写新代码，不做 commit 提交

✅ 标准答案步骤

1.在feature/login编写半成品代码，不 Add、不 Commit 修改Test.java，新增一段未完成代码，示例：

// 待完成：用户权限校验（半成品，不能提交）
public boolean checkPermission(String userId){
// TODO 待实现
}

观察：文件变成蓝色，代表已追踪文件发生改动，代码仅在工作区，没有暂存、没有提交。

2.执行 Stash Changes，储藏当前半成品代码 顶部菜单 Git → Stash Changes

• Stash message 填写备注：临时搁置登录权限校验开发

• 点击Stash

等价命令：git stash save "临时搁置登录权限校验开发"

现象：编辑器内刚才写的半成品代码消失，工作区回到干净状态，文件无修改。

3.切换到 main 分支修复线上 bug 右下角分支下拉，切换到main 修改Test.java修复 bug，完成后Ctrl+K提交，备注：fix: 修复main分支空指针bug，推送到远程 main。

4.切回feature/login分支，恢复储藏代码 右下角分支下拉，切回feature/login分支 顶部菜单 Git → Unstash Changes

• 在储藏列表选中刚才创建的 stash 记录

• 点击Apply Stash（应用储藏，保留储藏记录，可重复使用）

补充选项：Pop Stash = 应用储藏并删除这条储藏记录（开发最常用）

5.【进阶操作：查看多条储藏记录】 Git → View Stashes，可以看到所有 stash 堆栈；支持 Apply、Drop（删除指定储藏）、Clear（清空全部储藏）。

✅ 验证标准（操作完成核对）

1.执行 Stash 后，feature/login 工作区干净，看不到半成品代码。

2.切回 feature 分支，Unstash 之后，权限校验的半成品代码完整恢复。

3.View Stashes 面板可以看到储藏记录，备注文字和填写的一致。

📸截图指引

截图 1：Stash Changes弹窗，填写储藏备注

截图 2：View Stashes储藏列表页面，多条储藏记录

截图 3：Unstash 选择 Apply / Pop 的操作弹窗

💡 考点 & 易错点（面试高频）

1.Stash 作用：只储藏工作区、暂存区的未提交改动；不会储藏新增未追踪的文件（新建文件默认不进 stash）

2.Apply vs Pop

• Apply：取出储藏代码，储藏记录保留在堆栈中，可以多次复用

• Pop：取出储藏代码，取出后直接删除该条储藏记录，日常开发首选

3.Stash 是栈结构：后进先出，最新储藏的记录排在最上方。

坑 1：新建未 add 的文件，默认不会被 stash 保存；需要勾选Include untracked files。

坑 2：忘记 stash 直接切换分支，未提交修改会跟着带到目标分支，造成代码污染。

坑 3：多次 stash 堆叠，执行 pop 默认取出最新一条，不是第一条。

🧪拓展小练习（可选）

1.连续做 2 次 stash，模拟多次临时搁置，练习切换不同储藏记录 Apply。

2.测试 Drop，手动删除一条不需要的 stash 记录。

❓ 常见报错排查

1.Stash 之后代码没有消失：存在未追踪新建文件，勾选Include untracked files重新 stash。

2.Unstash 出现冲突：储藏代码和当前分支代码有差异，弹出冲突窗口手动合并。

3.View Stashes 为空：没有执行过 stash，或者所有 stash 都执行 pop 被删除。

四、代码冲突解决（必考、最实用）

练习题6：模拟多人并行开发，解决Pull代码冲突

场景

团队多人共同维护 main 分支，远程仓库 main 分支被其他同事修改了某一行代码；你本地 main 分支在同一行做了不同修改。执行 Pull 拉取远程代码时触发冲突，需要手动合并冲突，完成代码合并提交。

前置条件：

1.完成练习题 1~5，本地 main 分支与远程仓库连通

2.远程仓库可网页在线编辑代码，用来模拟同事提交

✅ 标准答案步骤

1.模拟同事在远程仓库修改代码 打开浏览器进入 Gitee/GitHub 远程仓库，在线编辑Test.java文件，修改某一行代码，提交。

提交备注：feat:同事修改main分支打印语句 此时远程 main 已经领先本地 main 一个提交。

2.在本地 IDEA 修改同一行代码（制造冲突关键点） 在 IDEA 中保持当前在 main 分支，打开Test.java，修改完全相同的那一行，写不一样的代码。 快捷键Ctrl+K，Commit 提交本地修改（不要 Push）。

现状：本地 main、远程 main 对同一行代码做了不同修改，Git 无法自动判断保留哪一份，拉取代码就会产生冲突。

3.执行 Pull 拉取远程代码 顶部菜单 Git → Pull 选择拉取 origin/main，确认拉取，弹出代码冲突窗口。

4.处理冲突，三种选项说明

• Accept Yours：保留本地代码，丢弃远程同事的修改

• Accept Theirs：保留远程代码，丢弃本地自己的修改

• Merge：手动合并（本次练习必须选 Merge）

5.手动合并代码 合并窗口三栏：

• 左侧：Your changes（本地代码）

• 右侧：Theirs changes（远程代码）

• 中间：Result（最终合并结果） 勾选需要保留的代码片段，调整中间结果，点击Apply完成合并。

合并完成后，IDEA 会自动将冲突文件加入暂存区。

6.提交合并结果并推送到远程 Ctrl+K，填写 commit

备注：merge:解决拉取代码产生的行冲突，执行 Commit。 Ctrl+Shift+K，Push 到远程 main 分支。

✅ 验证标准（操作完成核对）

1.Git Log 出现本次合并提交记录。

2.远程仓库刷新，文件是合并后的最终代码。

3.本地Test.java内容和远程仓库保持一致。

📸截图指引

截图 1：Pull 之后弹出的冲突弹窗，展示 Accept Yours / Accept Theirs / Merge 三个按钮

截图 2：Merge 三方对比合并窗口（左本地、右远程、中间结果）

截图 3：Git Log 查看冲突解决后的合并提交

💡 考点 & 易错点（面试高频）

1.冲突产生根本原因：同一个文件的同一行，两边同时修改，Git 无法自动判断取舍；不同行修改不会产生冲突，可以自动合并。

2.Pull 底层等价于：git fetch + git merge；先拉取远程更新，再合并到本地分支。

3.合并冲突只解决代码内容，不会自动生成提交，需要手动 commit。

坑 1：Pull 前不提交本地修改，容易造成工作区代码混乱丢失；Pull 前建议先 commit 或者 stash。

坑 2：合并时直接点 Accept Yours / Accept Theirs，会直接丢掉一方代码，真实项目谨慎使用。

坑 3：冲突解决完忘记 commit，文件处于未完成合并状态，后续操作会报错。

🧪拓展小练习（可选）

1.制造非同一行修改，执行 Pull，观察 Git 自动合并，不会触发冲突。

2.冲突合并一半，放弃合并，使用 Abort 终止本次 merge，代码恢复到 Pull 之前状态。

❓ 常见报错排查

1.冲突处理完，无法 Push：检查是否执行 commit 生成合并提交。

2.Pull 提示 working tree 有未提交改动：先 commit 或者 stash，再 pull。

3.合并完代码发现改错：可以查看 Git Log，找到本次合并提交，使用 revert 回滚。

五、代码回滚/撤销（高危操作必练）

练习题7：未Push的本地提交回滚（Reset三种模式）

场景

在本地 main 分支提交了错误代码，该提交还没有推送到远程仓库，需要撤销本次提交。练习 Reset 的 Soft、Mixed、Hard 三种模式，区分三种模式对工作区、暂存区的影响。

前置条件：

1.完成练习题 1~6，本地仓库正常

2.准备一条错误提交，禁止 Push 到远程（Reset 只适合未推送的提交）

✅ 标准答案步骤

1.创建错误提交 修改Test.java，随便写一段错误测试代码。 快捷键Ctrl+K，Commit 提交，

备注：test:错误测试提交。

⚠️ 重点：不要执行 Push，这条提交仅存在本地仓库。

2.打开 Git Log 面板，找到目标提交记录 右下角 Git → Log，找到错误提交的上一条正确提交记录，右键这条正确提交记录，

选择：Reset Current Branch to Here

3.选择 Reset 模式（依次分别测试 3 种模式，建议每次测试前重新创建错误提交）

(1)Soft（软重置）

撤销本次提交，代码修改保留，并且保留在暂存区。文件显示绿色。

等价命令：git reset –soft 提交hash

(2)Mixed（默认模式，混合重置）

撤销本次提交，代码修改保留，放到工作区，不进暂存区。文件显示红色。

等价命令：git reset 提交hash（不加参数默认 mixed）

(3)Hard（硬重置）

撤销本次提交，直接删除本次所有代码修改，彻底丢弃改动，不可恢复。谨慎使用！

等价命令：git reset –hard 提交hash

4.每测试一种模式，观察文件颜色、暂存区状态，记录差异。

✅ 验证标准（操作完成核对）

1.Soft：Git Log 中错误提交消失；代码还在，文件绿色（已 Add，暂存区）。

2.Mixed：Git Log 中错误提交消失；代码还在，文件红色（未 Add，工作区）。

3.Hard：Git Log 中错误提交消失；修改的代码直接消失，工作区干净。

📸截图指引

截图 1：Git Log 右键菜单 Reset Current Branch to Here

截图 2：Reset 弹窗，三种模式单选选项界面

截图 3：三种模式操作后，对比文件状态颜色截图

💡 考点 & 易错点（面试高频）

1.Reset 本质：移动分支指针，修改本地提交历史。

2.核心限制：Reset 只适用于还没有 push 到远程的提交。一旦 push 到公共分支，禁止使用 reset，会破坏远程仓库历史。

3.三种模式一句话总结

• Soft：撤销提交，代码留在暂存区（想重新提交）

• Mixed：撤销提交，代码留在工作区（需要重新 add 再 commit，默认）

• Hard：撤销提交，代码直接删掉（彻底丢弃改动）

坑 1：Hard 模式删除的本地修改，很难找回，练习前注意。

坑 2：把已经推送到远程公共分支的提交执行 reset，再强制 push，会造成团队仓库历史错乱。

坑 3：选错 Reset 目标提交节点，回滚到更早版本。一定要选中错误提交之前那条正确记录。

🧪拓展小练习（可选）

1.依次重复新建错误提交，分别测试 Soft、Mixed、Hard，对比三种模式差异。

2.总结三种模式的适用场景，整理笔记。

❓ 常见报错排查

1.Reset 选项灰色：选中的不是提交记录，或者当前有未提交修改，先 commit 或者 stash。

2.Hard 后代码丢失：无法直接恢复，提前做好备份。

3.Reset 后日志没变：选错提交节点，重新在 Git Log 找到正确提交。

练习题8：远程已推送代码回滚（Revert安全回滚）

场景

错误代码已经 Commit 并且 Push 到远程公共 main 分支，此时不能使用 Reset（Reset 会改写公共分支提交历史，影响团队）。使用 Revert，通过新增一条反向提交抵消错误代码，历史记录全部保留，安全回滚。

前置条件：

1.完成练习题 1~7

2.本地 main 分支提交一段错误代码，并且已经 Push 推送到远程 main 分支

✅ 标准答案步骤

1.制造一条已推送到远程的错误提交 修改Test.java，写入一段错误代码。 Ctrl+K提交，

备注：feat: 错误功能提交Ctrl+Shift+K执行 Push，把这条提交推送到远程 main。

此时远程仓库已经存在这条错误记录，团队其他人可能已经拉取该版本。

2.在 Git Log 找到需要撤销的错误提交 右下角打开 Git Log 面板，找到刚才这条feat: 错误功能提交记录，右键该提交，选择 Revert Commit。

等价命令：git revert 提交hash

原理：Git 自动生成反向代码，抵消这条提交里的修改，不会删除原有提交记录。

3.确认 Revert 自动生成的提交 IDEA 自动生成新的提交，commit 备注默认：

Revert "feat: 错误功能提交" 检查代码，确认错误代码已经被抵消。 点击 Commit，完成本地 revert 提交。

4.将 Revert 提交推送到远程仓库Ctrl+Shift+K打开 Push 窗口，推送 main 分支到远程 origin/main。

✅ 验证标准（操作完成核对）

1.Git Log 中同时保留原始错误提交 + Revert 回滚提交两条记录，不会删除旧提交。

2.打开Test.java，错误代码消失，代码恢复到错误提交之前的状态。

3.浏览器打开远程仓库，能看到 Revert 这条新增提交记录。

📸截图指引

截图 1：Git Log 右键菜单，Revert Commit选项

截图 2：Revert 自动生成的提交弹窗，查看默认 commit 信息

截图 3：Git Log 日志，展示原始提交和 Revert 回滚提交两条记录

💡 考点 & 易错点（面试高频）

1.Revert 核心原理：新增一条反向提交抵消代码，不修改已有提交历史，公共分支唯一安全回滚方案。

2.Reset vs Revert 对比（面试必考）

• Reset：移动分支指针，删除 / 改写历史；只能用于未 Push 的本地提交

• Revert：新增提交抵消改动，历史完整保留；公共分支已经 push 出去的错误提交必须用 Revert

坑 1：Revert 不是删除旧提交，只是新增提交把代码改回去，日志里两条记录都存在。

坑 2：连续多个提交需要回滚，要逐个 Revert，从最新错误提交往旧的依次执行。

坑 3：Revert 过程遇到冲突，需要手动合并代码，完成后继续提交。

🧪拓展小练习（可选）

1.Revert 完成后，再次查看 Git Log，对比 Reset（练习题 7）和 Revert 日志图形的区别。

2.尝试 Revert 上一步的 Revert 提交，把代码恢复回来。

❓ 常见报错排查

1.Revert 选项灰色：当前分支存在未提交修改，先 commit 或者 stash。

2.Revert 产生冲突：手动合并代码，确认最终代码，完成 commit。

3.Push 被拒绝：远程 main 有别人新提交，先 Git→Pull 拉取合并，再推送 Revert 提交。

六、Gitignore忽略文件实操（解决常见坑）

场景

项目中有 IDE 配置目录、编译输出目录、日志文件，不希望提交到 Git 仓库。需要配置.gitignore忽略这些文件；

重点练习高频坑：文件已经提交入库后，再写 gitignore 不会自动生效，需要清除 Git 缓存。

前置条件：

1.完成练习题 1~8

2.项目中存在.idea、target这类 IDE / 编译产生的目录

✅ 标准答案步骤

1.在项目根目录新建.gitignore文件 在项目最外层根目录，新建文件，名称为.gitignore，写入下面配置：

# IDEA配置目录 .idea/ # Maven编译输出目录 target/ # 编译输出 out/ # 日志文件 *.log # IDEA模块文件 *.iml

说明：/代表目录；*是通配符，匹配任意文件名。

2.复现经典坑点：先把.idea 目录下文件提交到仓库 打开.idea目录下的xxx.iml文件，Add 并 Commit 提交，

备注：feat: 提交iml文件（模拟误提交），可推送到远程。

此时文件已经被 Git 追踪管理。

3.在.gitignore 增加.idea/忽略规则，观察现象 已经提交到仓库的文件，即使写入.gitignore，Git 依旧会继续追踪，不会自动忽略，这就是 gitignore 最常踩的坑。

4.IDEA 内置终端执行命令，移除 Git 缓存（本地文件保留，不再被 Git 追踪） 打开 IDEA 底部 Terminal 终端，执行命令：

git rm –cached .idea/*.iml

–cached 参数含义：只从 Git 版本库移除追踪，本地磁盘上的文件不会删除。

5.提交本次移除追踪操作 Ctrl+K打开提交窗口，勾选被取消追踪的 iml 文件，commit

备注：chore: 移除.idea文件版本追踪，由gitignore忽略，可 Push 到远程。

✅ 验证标准（操作完成核对）

1..idea目录内文件不再显示为 Git 追踪文件，不再出现红色 / 蓝色版本标记。

2.修改.idea下文件，Git 不会识别为变更。

3.Git Log 可以看到一条移除文件追踪的提交记录。

4.新增target目录，里面的文件不会被 Git 识别追踪。

📸截图指引

截图 1：.gitignore文件完整内容界面

截图 2：Terminal 执行 git rm –cached 命令

截图 3：移除追踪前后，.idea 目录文件颜色状态对比

💡 考点 & 易错点（面试高频）

1.gitignore 生效前提：文件还没有被 Git 纳入版本追踪。一旦已经 commit 入库，gitignore 规则对它无效。

2.git rm –cached：只删除仓库里的追踪记录，本地文件保留不动；不带 –cached 会直接删除本地文件。

3.gitignore 只忽略未被追踪的文件；已经在版本库的文件不受该文件控制。

坑 1：把.gitignore放在 src 子目录，只能忽略当前目录下文件，一般放在项目根目录。

坑 2：写规则时多空格、换行错误，导致忽略失效。

坑 3：不要写.git/，不能忽略.git 文件夹，仓库核心目录。

🧪拓展小练习（可选）

1.新建test.log日志文件，观察是否被 gitignore 自动忽略。

2.测试git rm –cached target/ -r，递归移除整个 target 目录的追踪。

❓ 常见报错排查

1.git rm –cached 提示找不到文件：核对路径，路径大小写、目录名称要和项目一致。

2. .gitignore 新建后看不到文件：Windows 系统隐藏文件，开启查看隐藏项目。

3.文件依旧被追踪：确认执行了git rm –cached并且完成 commit 提交。

七、综合压轴题（企业真实开发流程）

练习题10：完整团队开发流程演练

场景

模拟企业真实团队开发全流程：从拉取主分支最新代码、创建功能分支开发、中途临时修复线上 bug、回来继续开发、合并主分支代码解决冲突、合并分支、推送远程、清理废弃分支。

串联前面 9 个练习所有知识点。

前置条件：

1.已完成练习题 1~9，仓库、远程仓库正常连通

2.main 为公共稳定主分支

✅ 标准答案步骤

1.拉取 main 主分支最新代码 右下角切换到main分支，顶部菜单 Git → Pull，拉取远程 origin/main 最新代码，保证本地 main 和远端保持同步。

2.创建并切换功能分支 右下角分支下拉 → New Branch，分支名feature/pay，勾选Checkout branch，点击 Create。

等价命令：git checkout -b feature/pay

3.在 feature/pay 分支开发业务代码，多次提交 修改Test.java，新增支付相关代码，分 2 次开发并执行Ctrl+K提交：

• 第一次提交备注：feat: 新增支付基础结构

• 第二次提交备注：feat: 新增支付金额校验

4.开发中途接到紧急 bug，使用 Stash 储藏半成品 代码写到一半，还不适合提交。顶部菜单 Git → Stash Changes Stash

备注：临时搁置支付功能开发，紧急修复mainbug，点击 Stash。

现象：工作区代码清空，回到干净状态。

5.切换 main 分支，修复线上 bug 右下角切换到main分支，修改代码修复 bug。Ctrl+K提交，

备注：fix: 修复支付空指针bug；Ctrl+Shift+K推送到远程 main。

6.切回 feature/pay 分支，恢复储藏代码 右下角切回feature/pay分支。Git → Unstash Changes，选中刚才的 stash 记录，执行Pop Stash（取出并删除储藏记录）。半成品代码恢复。

7.拉取 main 最新代码，处理冲突 执行Git → Pull，拉取 main 分支最新代码。 若存在代码冲突，选择 Merge 手动合并，调整代码后 Apply 保存，完成 commit。

8.将 feature/pay 合并进 main 分支 右下角切换回main分支； 分支列表选中feature/pay，点击Merge into Current，把功能分支代码合并到 main。

无冲突直接合并；有冲突继续手动处理。

9.推送合并后的 main 分支到远程Ctrl+Shift+K打开 Push 窗口，推送 main 分支到远程 origin/main。

10.清理本地废弃分支（可选） 分支列表选中feature/pay，选择 Delete，删除本地无用分支；

可选勾选：Delete remote branch（如果远程也有该分支，一并删除）

✅ 验证标准（操作完成核对）

1.Git Log 完整看到：bug 修复提交、支付功能提交、合并提交，完整开发链路。

2.远程 main 分支包含支付功能代码 + bug 修复代码。

3.本地feature/pay分支已删除，仓库干净。

4.整个流程无代码丢失，冲突处理正常。

📸截图指引

截图 1：Git Log 完整分支流转图，展示整个开发流程的提交链路

截图 2：Delete Branch 删除废弃分支弹窗

💡 考点 & 易错点（面试高频）

1.团队开发规范：不在 main 分支直接开发，所有新功能新建 feature 分支。

2.遇到紧急 bug 优先 stash 搁置当前工作，不要随意 commit 半成品代码。

3.合并前一定要 pull 主分支最新代码，减少大规模冲突。

4.开发完成合并到 main，及时清理废弃分支，保持仓库整洁。

坑 1：忘记 stash 直接切换分支，半成品代码带到 main 分支，污染主分支。

坑 2：合并前不拉取 main 最新代码，合并产生大量冲突。

坑 3：合并完成忘记 push，远程代码没有更新。

🧪拓展小练习（可选）

1.重复整套流程，本次 feature 分支合并改用 Rebase 方式，对比 Merge 与 Rebase 的日志差异。

2.故意制造冲突，完整走完冲突合并流程。

❓ 常见报错排查

1.Stash 失败：工作区存在未追踪文件，stash 时勾选 Include untracked files。

2.Merge 冲突：手动合并代码，确认最终结果后提交。

3.Push rejected：远程 main 存在别人新提交，先 Pull 拉取，处理冲突后再 Push。

八、常见报错修复实操（排错能力）

1.Push rejected

原因：远程分支有别人新提交，本地版本落后。解决：先 Pull 拉取、合并冲突，再 Push。

2.Can't start Git

解决：File → Settings → Version Control → Git，重新选择 git.exe 路径，点击 Test。

3.文件提交列表看不到文件

原因：①没有 Add；②被.gitignore 忽略。

4.SSH 拉取失败

解决：检查 SSH 密钥是否添加到 Gitee/GitHub，IDEA 内置终端执行ssh -T git@gitee.com测试连通。

📝 自查清单（做完所有练习对照）

• 能够独立初始化 Git、绑定远程仓库

• 新建 / 切换 / 合并分支，区分 Merge 和 Rebase 适用场景

• Stash 储藏、恢复、查看多条储藏记录

• 独立处理代码冲突，手动 Merge

• 区分 Reset 三种模式，知道 Revert 适用场景

• 理解 gitignore 不生效的底层原因，会清除仓库缓存

• 能排查 Push rejected、Git 路径错误等常见问题

九、做题验收标准

1. 全程无手动Git命令，纯IDEA可视化操作完成

2. 熟练区分Merge/Rebase、Reset/Revert、Pull/Fetch

3. 能独立处理代码冲突、代码回滚、临时代码储藏场景

4. 彻底解决gitignore不生效、推送失败等高频问题