版本控制与协作：Git核心概念、分支策略、Code Review流程、Git Hooks自动化

说实话，版本控制这件事，我见过太多团队栽跟头了。

有人把Git当网盘用，有人分支乱成一锅粥，还有人合并代码全靠胆量。嗯，今天咱们就把这块彻底聊透。我会结合自己这些年踩过的坑，把Git的核心概念、分支策略、Code Review流程，还有自动化那点事，一次性说清楚。

Git核心概念：别只记命令，要理解本质

很多人学Git，上来就背命令。其实没必要。你只要搞懂三个东西：工作区、暂存区、版本库。

工作区：你写代码的地方，就是你的项目目录。

暂存区：一个临时存放区，你决定哪些改动要提交。

版本库：Git真正存数据的地方，每次提交就是一个快照。

我刚开始带团队时，有个同事总喜欢把所有文件一股脑 git add .。结果有一次把调试日志也提交上去了，线上出了事故。后来我定了个规矩：提交前必须用 git diff --cached 看一眼。

还有一个概念很重要——HEAD指针。它指向你当前所在的提交。切换分支，其实就是移动HEAD。记住这个，你就能理解为什么Git切换分支这么快了。

# 查看当前HEAD指向
git log --oneline -1

# 查看所有分支和HEAD关系
git log --oneline --graph --all

小技巧：我个人习惯用 git reflog 来恢复误操作。有一次我不小心删了一个分支，就是靠它找回来的。这命令能记录你所有的HEAD移动历史，堪称后悔药。

分支策略：Git Flow，我用了8年的方案

分支策略这东西，没有银弹。但我个人最推荐的是Git Flow。它结构清晰，适合有固定发布周期的项目。

Git Flow的核心分支有5个：

分支类型	命名规则	用途
master	master	生产环境代码，只合并，不直接开发
develop	develop	日常开发主分支，所有功能分支从这里拉出
feature	feature/xxx	新功能开发，完成后合并回develop
release	release/x.x.x	发布前准备，只修bug，不加新功能
hotfix	hotfix/xxx	线上紧急修复，从master拉出，修完合并回master和develop

下面这张图，是我自己画的Git Flow流程。你看一眼就明白了。

注意：Git Flow不适合所有项目。如果你做的是持续交付、每天发版的项目，建议用GitHub Flow或Trunk-Based Development。我曾经在一个移动端项目里硬套Git Flow，结果release分支积压了三天没合并，差点耽误上线。

Code Review流程：别让Review变成形式主义

Code Review这件事，我见过两种极端：一种是完全不Review，代码直接合；另一种是Review得比写代码还累，一个PR拖三天。

我的经验是：Review要快，但要狠。

一个健康的Code Review流程应该是这样的：

提交PR前自检：自己先跑一遍diff，确保没有调试代码、没有拼写错误。
PR描述要清晰：写清楚改了啥、为什么改、怎么测试的。别只写一句“修复bug”。
Reviewer要专注：一次Review不要超过200行代码改动。超过这个数，人的注意力就会下降。
评论要对事不对人：说“这个函数命名不够清晰”，别说“你写的什么玩意”。
合并前必须通过CI：所有自动化测试必须绿。这是底线。

我个人的Review清单：

代码逻辑是否正确？有没有边界情况没处理？
有没有重复代码？能不能复用现有工具函数？
异常处理是否到位？日志打了吗？
性能有没有隐患？比如不必要的拷贝、循环嵌套过深。
单元测试覆盖了吗？新功能有没有对应的测试用例？

我曾经Review过一个PR，改动量不大，但把一个全局变量改成了局部变量。结果那个全局变量被另一个模块依赖，上线后直接崩溃。从那以后，我Review时一定会问一句：这个改动会影响哪些模块？

Git Hooks自动化：把重复劳动交给机器

Git Hooks，说白了就是Git的钩子。你在执行某些Git操作时，它会自动触发一段脚本。这东西用好了，能省下大量人工检查的时间。

常用的Hook有这些：

Hook名称	触发时机	常见用途
pre-commit	执行git commit之前	代码格式化、静态检查、禁止提交大文件
commit-msg	提交信息写入后	检查提交信息格式是否符合规范
pre-push	执行git push之前	运行单元测试、检查分支命名
post-merge	合并完成后	自动安装依赖、更新子模块

我分享一个我项目里常用的pre-commit脚本。它会在提交前自动格式化代码，并检查是否有调试语句残留。

#!/bin/bash
# pre-commit hook: 代码格式化和静态检查

echo "🔍 正在运行 pre-commit 检查..."

# 1. 代码格式化（以clang-format为例）
FILES=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(cpp|hpp|c|h)$')
if [ -n "$FILES" ]; then
    echo "📝 格式化代码..."
    echo "$FILES" | xargs clang-format -i -style=file
    echo "$FILES" | xargs git add
fi

# 2. 禁止提交调试语句
if git diff --cached | grep -E '^\+\s*(printf|cout|cerr|std::cout|std::cerr)' > /dev/null; then
    echo "❌ 错误：提交中包含调试输出语句！"
    echo "   请移除 printf/cout/cerr 后再提交。"
    exit 1
fi

# 3. 检查文件大小（超过1MB禁止提交）
THRESHOLD=1048576
for file in $(git diff --cached --name-only); do
    if [ -f "$file" ]; then
        size=$(stat -f%z "$file" 2>/dev/null || stat -c%s "$file" 2>/dev/null)
        if [ "$size" -gt "$THRESHOLD" ]; then
            echo "❌ 错误：文件 $file 超过1MB！"
            echo "   请使用 Git LFS 管理大文件。"
            exit 1
        fi
    fi
done

echo "✅ pre-commit 检查通过！"

推荐工具：手动写Hook脚本有点麻烦。我建议用 husky（前端项目）或 pre-commit（Python项目）这类工具来管理Hook。它们能帮你自动安装、版本控制Hook脚本，团队里每个人都能用上同一套规则。

嗯，Git Hooks这东西，配置一次，受益终身。我团队现在所有项目都强制要求pre-commit和commit-msg两个Hook。前者保证代码质量，后者保证提交信息规范。刚开始有人嫌麻烦，但用了一周后，没人再抱怨了——因为代码Review时少了很多无意义的格式争论。

好了，版本控制与协作这块，核心就是这些。记住：工具是死的，流程是活的。找到适合你团队的节奏，比什么都重要。

📚 课程目录

版本控制与协作：Git核心概念、分支策略、Code Review流程、Git Hooks自动化

Git核心概念：别只记命令，要理解本质

分支策略：Git Flow，我用了8年的方案

Code Review流程：别让Review变成形式主义

Git Hooks自动化：把重复劳动交给机器