冲突解决最怕一键乱选。VSCode 的 3-way Merge Editor 把冲突拆成 Current、Incoming、Result: 你可以看清当前分支、对方分支和最终结果,再决定接受哪一边或手动组合。

Git 相关设置不要太花。目标是让变更更可见、提交更谨慎、同步更可控。

{
  "git.autofetch": true,
  "git.confirmSync": true,
  "git.enableSmartCommit": false,
  "git.openRepositoryInParentFolders": "always",
  "diffEditor.ignoreTrimWhitespace": false,
  "diffEditor.renderSideBySide": true,
  "mergeEditor.enabled": true
}

Lab 1 — 用 hunk stage 拆两个提交

目标:在同一个文件里做两个意图不同的改动,再用 VSCode 拆成两个 commit。

1. 创建或打开一个 Git 仓库,确保工作树干净
2. 在同一个文件中改一个 bug,再顺手改一段注释或格式
3. 打开 Source Control,点击该文件进入 diff
4. 只 stage bug 修复对应的 hunk 或 selected ranges
5. 提交为 fix: handle empty input
6. 再 stage 剩下的注释 / 格式改动,提交为 docs: clarify input behavior

Lab 2 — 模拟并解决一个 merge conflict

目标:熟悉 Merge Editor 的 Current / Incoming / Result。

git checkout -b feature/current
echo "timeout=3000" > config.txt
git add config.txt && git commit -m "add timeout config"
git checkout -b feature/incoming
echo "timeout=5000" > config.txt
git commit -am "increase timeout"
git checkout feature/current
echo "timeout=1000" > config.txt
git commit -am "lower timeout for local dev"
git merge feature/incoming

1. 运行上面的命令制造冲突
2. 在 Source Control 中找到冲突文件
3. 选择 Resolve in Merge Editor
4. 观察 Current / Incoming / Result 三个区域
5. 手动决定最终 timeout 值,保存 Result
6. stage 文件并完成 merge commit

Lab 3 — 用 Timeline 找回一次误改

目标:理解 Timeline 与 Git history 的关系。

1. 打开一个已有文件,做一次小改动并保存
2. 再做第二次改动,故意删掉一段有用内容
3. 打开 Explorer 中的 Timeline 面板
4. 查看该文件最近的保存点或 Git 提交记录
5. 对比历史版本,把误删内容恢复回来
6. 最后用 Source Control diff 确认恢复结果符合预期

1. Changes、Staged Changes、commit 三者分别对应 Git 的什么概念?
2. 什么时候应该 stage file,什么时候应该 stage hunk 或 selected ranges?
3. 提交前为什么要再看一遍 Staged Changes 的 diff?
4. Merge Editor 中 Current、Incoming、Result 分别表示什么?
5. Timeline 和 blame 分别适合回答什么历史问题?