版本控制基石：Git 与 Git Flow 工作流，从单人提交到团队协作
说实话，我见过太多团队在版本控制上栽跟头了。有人把 Git 当网盘用，有人一天提交八百次，还有人合并冲突时直接删了同事的代码。嗯，这些坑我都踩过。今天咱们就聊聊，怎么把 Git 从一个人的玩具，变成团队协作的利器。
为什么非要用 Git？
你可能觉得，我一个小项目，用压缩包备份不也挺好？我以前也这么想。直到有一次，我同时维护三个版本的功能，压缩包命名变成了“最终版”、“最终版2”、“打死不改版”……你懂的，那场面简直灾难。
Git 的核心价值，说白了就三点：
- 历史追溯：每一行代码是谁改的、什么时候改的、为什么改，清清楚楚
- 并行开发：几个人同时改同一个文件，互不干扰
- 版本回退：改坏了？没关系，一秒回到上一秒
我个人习惯，新项目第一件事就是 git init。哪怕只有我一个人写代码，这个习惯也帮我挽回过好几次误删文件的尴尬。
单人开发：先学会走路
一个人用 Git，其实就几个命令。但别小看这几个命令，我见过有人用了三年 Git，还在用 git add . 和 git commit -m "update"。这哪是版本控制，这是版本记录仪。
我建议的单人工作流是这样的：
# 初始化仓库
git init
# 添加文件到暂存区
git add index.html
# 提交，写清楚这次改了啥
git commit -m "feat: 添加首页导航栏"
# 查看历史
git log --oneline这里有个小技巧：提交信息别偷懒。我吃过一次亏，有一次提交信息写的是“改了点东西”，结果三天后我自己都看不懂改了啥。后来我强制自己用 type: description 的格式，比如 fix: 修复登录按钮点击无响应。你想想看，半年后回来看，是不是一目了然？
git diff 看一眼改了啥。别问我为什么，有一次我差点把数据库密码提交上去。
分支管理：从单行道到立交桥
单人开发时，你可以在 main 分支上直接干活。但一旦开始团队协作，这就行不通了。为什么？因为两个人同时改同一个文件，冲突会把你逼疯。
分支，说白了就是平行宇宙。你在你的宇宙里改代码，我在我的宇宙里改代码，互不干扰。等各自改完了，再合并回来。
我常用的分支操作：
# 创建并切换到新分支
git checkout -b feature/login-page
# 在新分支上干活
git add .
git commit -m "feat: 完成登录页面布局"
# 切回主分支
git checkout main
# 合并功能分支
git merge feature/login-page这里要注意：合并前一定要先拉取最新的代码。我曾经犯过一个错误，在旧代码上合并新功能，结果冲突多到想哭。后来我养成了习惯：git pull --rebase 先更新本地分支，再合并。
git merge --no-ff，结果生成了一个巨大的合并节点，历史记录乱成一锅粥。后来我改用 git merge --squash，把多个小提交压缩成一个，历史干净多了。
Git Flow：团队协作的交通规则
团队一超过三个人，光靠分支就不够了。你需要一套规则，告诉大家什么时候该建分支、什么时候该合并、分支该叫什么名字。这就是 Git Flow 的由来。
Git Flow 把分支分成几类：
| 分支类型 | 命名规则 | 用途 |
|---|---|---|
| 主分支 | main |
生产环境代码，只允许合并，不允许直接修改 |
| 开发分支 | develop |
日常开发集成分支，所有功能分支从这里拉出 |
| 功能分支 | feature/xxx |
开发新功能，完成后合并到 develop |
| 发布分支 | release/x.x.x |
准备发布时创建，只修 bug，不加新功能 |
| 热修复分支 | hotfix/xxx |
紧急修复生产环境问题，直接从 main 拉出 |
我在项目中遇到过最典型的场景是这样的：产品经理说“下周要上线一个支付功能”。好，我从 develop 拉一个 feature/payment 分支。开发了三天，测试通过，合并回 develop。然后从 develop 拉一个 release/1.2.0 分支，修了几个小 bug，最后合并到 main 并打上标签 v1.2.0。
整个过程就像流水线一样，每个人都知道自己该干什么。说白了，Git Flow 不是技术问题，是管理问题。
团队协作的常见坑
光有流程还不够，执行中全是坑。我挑几个最常见的说说：
- 合并冲突：两个人改了同一行代码。解决办法？别慌，用
git mergetool或者手动编辑，然后git add标记已解决。我建议团队里指定一个人负责解决复杂冲突，避免多人同时操作。 - 提交信息不规范：有人写“fix”，有人写“修改”，还有人写“.”。我建议团队统一用 Conventional Commits 规范，比如
feat、fix、docs、refactor。这样生成 changelog 都省事了。 - 大文件提交：有人把 500MB 的日志文件提交了，结果仓库变得巨慢。解决办法：用
.gitignore忽略不需要的文件，或者用 Git LFS 管理大文件。
我的经验之谈：团队协作最怕的不是技术问题，是沟通问题。我建议每次合并前，在群里喊一声“我要合并 feature/login 到 develop 了，有冲突的吱一声”。别小看这一句话，能省下半天解决冲突的时间。
从单人提交到团队协作的转变
你可能会问：我一个人用 Git Flow 是不是太复杂了？没错，单人开发用 Git Flow 确实有点杀鸡用牛刀。我建议这样过渡：
- 第一阶段：单人开发，只用
main分支，学会add、commit、log、diff - 第二阶段：开始用
feature分支，学会branch、checkout、merge - 第三阶段：团队协作，引入 Git Flow，学会
release、hotfix、tag
我记得有个团队，一开始就上 Git Flow，结果新人完全懵了，天天问“我该从哪个分支拉代码”。后来我建议他们先从简单的分支模型开始，等大家熟练了再逐步加规则。你想想看，步子迈太大，容易扯着蛋。
最后说一句：版本控制不是目的，协作才是。工具只是手段，别为了用 Git 而用 Git。找到适合你们团队的节奏，比什么都重要。