Git 与开发协作

学习目标

这一课练习一个项目的日常协作闭环：开分支、做修改、检查差异、写提交信息、处理冲突、保护未提交的工作。读完你应该能独立完成一次「分支上开发 → 合并回主干」的完整流程，并且写出让队友看得懂的提交信息。

问题场景

你直接在 main 上改代码，改到一半同事喊你修个紧急 bug——你的半成品还没法运行，提交上去污染历史，不提交又怕丢。git 的分支（branch，指向某次提交的可移动指针）就是为这个场景准备的：半成品放在分支上，主干随时能拉出去修 bug。另一个高频事故是提交信息写「修改了一些文件」，两周后没人知道那次提交干了什么，包括你自己。

核心解释

日常流程五步，在本机任意仓库跟一遍：

git switch -c feat/course-filter   # 建并切换到新分支
# ...修改文件...
git diff                           # 逐行检查：我到底改了什么
git add courses.css lessons.mdx    # 挑选要提交的改动
git commit -m "课程筛选支持按学时排序"
git switch main && git merge feat/course-filter

提交信息是写给三个月后的自己的。一个够用的标准：第一行说清「行为上改变了什么」，用完整句子，不超过 50 字：

# 差：「修改了一些文件」「fix bug」「update」
# 好：
课程筛选支持按学时排序

筛选栏新增学时下拉；筛选结果默认按学时升序。
顺带修复筛选后分页总数不刷新的问题。

改动没做完又必须切分支时，用 stash（暂存架，把未提交改动临时收起来的机制）：

git stash push -m "筛选做到一半"  # 收起未提交改动，工作区变干净
git switch main                   # 放心去修 bug
# ...修完回来...
git switch feat/course-filter
git stash pop                     # 取回半成品

示例拆解

冲突不可怕，可怕的是不懂它在说什么。两个人改了同一行，合并时 git 无法决定用谁的，就把两个版本都写进文件并用标记圈出来：

<<<<<<< HEAD
total = base * 1.1
=======
total = base * 1.15
>>>>>>> feat/discount

• 处理动作：打开文件，删掉标记行，留下正确的结果（可能是一边，也可能是合并后的新写法），然后 git add 该文件并 git commit 完成合并。
• 验证别只看能不能运行：git diff main feat/discount 对比最终差异，确认行为符合预期。
• 每步之后用 git status 确认状态：哪些改动已暂存、哪些还没跟踪、当前在哪个分支——迷路时它是地图。

动手任务

本课没有在线实验，本机完成（没有仓库就 git init 一个练手仓库）：

1. 建分支改一行代码并提交，提交信息按本课标准写；用 git log --oneline 检查信息是否说清了行为变化。
2. 制造一次冲突：两个分支改同一行，合并触发冲突后手动解决并完成合并提交，用 git diff 确认最终结果。
3. 在工作区故意留一个未提交的改动，git stash push 收起后确认 git status 干净，再 git stash pop 取回，确认改动原样还在。

常见错误

• git add . 成习惯：把调试临时文件、密钥一起提交了；先看 git status，再逐个文件 add。
• 提交信息写「改了什么文件」而不是「改变了什么行为」：diff 已经说明改了哪个文件，信息该回答「为什么改、行为有何不同」。
• 解决冲突时两边都保留：删标记时把两版代码都留下，编译能过但逻辑重复；解决完必须检查行为。
• 怕丢东西不敢切分支：未提交改动用 stash 收起，已提交的都在历史里；git 几乎不会弄丢已提交的内容，先 git status 看清楚。

检查与复盘

完成下方检查题确认理解。自查清单：

• 能不看笔记走完「建分支 → 提交 → 合并」流程
• 最近一次提交的信息能让不了解上下文的人看懂行为变化
• 知道 stash 的用途，并用它保护过一次未提交的工作

参考资料

• Pro Git 中文版：分支简介 —— 分支模型的权威讲解
• git commit 官方文档 —— 提交的完整参数
• git stash 官方文档 —— 暂存与恢复未提交改动