Git = 版本管理
🎯 学完这课你能
- 理解 commit（存档）、branch（分支）、merge（合并）三个核心概念
- 看懂 CC 在用 Git 做什么
- 不再害怕"版本冲突"这个词
Git 不是只在出事时才出现的黑框命令，而是帮你记录变化、隔离试验、同步协作的一整套工作习惯。看懂它，后面你和 CC 的配合会稳很多。
你有没有经历过这种场景：一份 Word 文档改了十几版，桌面上躺着 方案v1.docx、方案v2-老板改.docx、方案v3-最终版.docx、方案v3-最终版-真的最终.docx……
Git 就是代码世界里解决这个噩梦的工具。它不是复制粘贴，而是自动记录每一次改动的历史，随时可以回退、对比、合并。
Git = 公司的制度版本管理系统
Repository（仓库） = 一个项目的全部历史档案
Commit（提交） = 一次存档，附带"这次改了什么"的说明
Branch（分支） = 平行宇宙——在不影响正式版的前提下试新方案
Merge（合并） = 把试验成功的新方案正式纳入制度
Pull / Push = 从远程仓库取最新版 / 把你的改动推上去
一个 commit 最好只记录一个明确变化。这样以后回看历史时，你和 CC 才知道“这一笔到底是修了什么”。
commit 是本地存档，push 是同步到远程，merge 是把另一条分支的成果正式并进来，别混着理解。
只要你心里在想“我想试试看”，那通常就该开 branch，而不是直接在主线一边试一边祈祷不要出事。
merge conflict 的本质是 Git 不想替你瞎猜。它把两个版本摆出来，请你决定保留哪个，而不是说项目彻底报废。
Git 的时间线
想象你在做绩效系统，每次改代码后 commit 一次：
Branch（分支）= 平行宇宙
假设你的绩效系统已经在线上跑了，突然老板说："试试加个 AI 智能评语功能吧"。
你肯定不想直接在正式版上改——万一改坏了呢？这时候就用 branch：
Branch 就像试用期：
- 新功能先在"试用期分支"里开发和测试
- 确认没问题后，merge（合并）到正式分支
- 如果试验失败，直接删掉分支——正式版毫发无损
你会看到 CC 执行的 Git 命令
CC 在帮你做项目时，经常会跑这些 git 命令。现在你知道它们在干什么了：
git status
"看看现在有什么文件被改了"——相当于查看待办事项清单
git add .
"把所有改动放进'准备提交'的篮子"——相当于把文件放到签字台上
git commit -m "添加登录功能"
"正式存档，并写一句备注"——相当于签字盖章，存入档案室
git push
"把本地的存档推到远程服务器（GitHub）"——相当于把文件上传到公司云盘
git pull
"从远程服务器拉取最新版本"——相当于从云盘下载最新文件
git checkout -b feature/xxx
"创建一个新分支并切换过去"——相当于开一个新的平行宇宙
git log --oneline
"查看历史存档记录"——相当于翻阅档案室的变更日志
Merge Conflict（合并冲突）
有时候两个人同时改了同一行代码，Git 不知道该听谁的——这就是合并冲突。
合并冲突 = 两个部门对同一条规定有不同意见
Git 会把两个版本都摆出来，让你（或 CC）决定保留哪个。它不会自作主张。
冲突长这样：
翻译：HEAD（当前版本）叫 "绩效考评系统 v2"，而 feature/rebrand 分支想改成 "深度赋智绩效平台"。你需要选一个保留（或者合并成新的表述）。
看到 Git 操作时，先这样理解
git status、git log 这类只是看；commit、merge、reset 才是在改变版本状态。
commit 还只是你电脑上的存档，push 才会同步到 GitHub。别把“我存了”误解成“大家都看到了”。
如果是试新功能，优先 branch；如果是把试验成果纳入主线，才考虑 merge。
合并冲突不是仓库崩了，而是 Git 在请求你做决定。先看双方改了什么，再选保留哪边或手动合成新版。
📝 小测验
你想在不影响线上运行的绩效系统的前提下，试验一个新的"AI 自动写评语"功能。应该怎么做？
📝 小测验 2
git commit -m "fix login bug" 这条命令做了什么？
📝 小测验 3
出现 merge conflict 时，Git 会怎么做？