Git = 版本管理

Track A: 工程化 ~25 分钟

🎯 学完这课你能

你有没有经历过这种场景:一份 Word 文档改了十几版,桌面上躺着 方案v1.docx方案v2-老板改.docx方案v3-最终版.docx方案v3-最终版-真的最终.docx……

Git 就是代码世界里解决这个噩梦的工具。它不是复制粘贴,而是自动记录每一次改动的历史,随时可以回退、对比、合并。

Git = 公司的制度版本管理系统
Repository(仓库) = 一个项目的全部历史档案
Commit(提交) = 一次存档,附带"这次改了什么"的说明
Branch(分支) = 平行宇宙——在不影响正式版的前提下试新方案
Merge(合并) = 把试验成功的新方案正式纳入制度
Pull / Push = 从远程仓库取最新版 / 把你的改动推上去

Git 的时间线

想象你在做绩效系统,每次改代码后 commit 一次:

初始化项目 Day 1 添加登录页面 Day 2 实现自评功能 Day 5 修复评分 bug Day 6 添加 360 环评 Day 8 main 分支(正式版) git revert — 可以随时回到这里
关键优势:每个 commit 都是一个存档点。如果第 6 天修 bug 的时候改坏了别的东西,可以直接回到第 5 天的状态——不需要 Ctrl+Z 按一百次。

Branch(分支)= 平行宇宙

假设你的绩效系统已经在线上跑了,突然老板说:"试试加个 AI 智能评语功能吧"。

你肯定不想直接在正式版上改——万一改坏了呢?这时候就用 branch

main 正常运行 合并成功! feature/ai-comment 开始试验 调 AI 接口 测试通过 merge

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 const title = "绩效考评系统 v2"; ======= const title = "深度赋智绩效平台"; >>>>>>> feature/rebrand

翻译:HEAD(当前版本)叫 "绩效考评系统 v2",而 feature/rebrand 分支想改成 "深度赋智绩效平台"。你需要选一个保留(或者合并成新的表述)。

📝 小测验

你想在不影响线上运行的绩效系统的前提下,试验一个新的"AI 自动写评语"功能。应该怎么做?

📝 小测验 2

git commit -m "fix login bug" 这条命令做了什么?

📝 小测验 3

出现 merge conflict 时,Git 会怎么做?

← 第 3 课:技术栈 第 5 课:包管理 & 依赖 →