一、为什么需要自定义工作流

每个团队在刚开始用Git的时候，基本都是把代码往仓库一推，大家各自拉各自的分支，遇到冲突就喊人。刚开始人少，项目小，这样勉强还能转。等团队到了十几个人，或者项目开始同时维护多个版本的稳定版和开发版，问题就冒出来了：今天张三改的代码覆盖了李四的逻辑，明天王五把测试分支直接推到生产分支，回滚都不知道从哪里找起点。这时候，大家才意识到，Git不是装上了就会自动让团队有序的，它就像一堆乐高零件，需要你按照团队的默契和规则，搭出适合自己的工作流。

自定义工作流，说白了就是提前把“代码怎么进、怎么出、谁负责合并、提交信息怎么写、分支怎么命名”这些琐事定下来。这些规则不是束缚，而是让所有人在同一个框架里轻松配合的缓冲垫。工作流设计得好，新同事一天就能融入；设计得别扭，老同事也会天天踩坑。

Git本身提供了很多底层的零件：分支、提交、合并、变基、钩子、远端引用。有一套设计良好的工作流，就是把这些零件组合成指定方向的小流水线。下面我们先把这些零件的脾气摸清楚，再一步步设计流程。

二、先搞懂Git的底层机制

很多人觉得Git难，是因为对着命令死记硬背，没想明白背后是怎么一回事。Git仓库里最重要的概念就是“提交对象”和“指针”。每一次提交，都会生成一个包含“内容快照”“作者信息”“父提交引用”的对象。而分支无非就是一个会自己移动的指针，指向某一次提交。HEAD同样是一个指针，只不过它指向“当前所在的分支”。

生活化一点，你可以把提交想象成游戏里的存档点。分支就是写在不同存档位置的表情符号，当你切换分支时，工作区就会变成那个存档点的样子。HEAD则像是“你正在看哪条路”的路标。合并，就是把两条路的改动混到一起；变基，则是把一条路的起点挪到另一条路的末端。

比如你新建一个仓库并提交三次，用一条查看日志的命令，能看到类似下面的结构：

# 技术栈：Git
# 查看提交历史，并显示分支和当前指针的位置
git log --oneline --graph --decorate --all

输出结果里，主分支指针停在最新提交上，当前分支标记也表示在这里。当你创建新分支并切换过去，当前分支指针就会转向这个新分支，但提交对象并没有变化。这就是Git神奇的地方：它不复制文件，只是移动一些很小的指针。

理解了指针，很多命令就不再难懂。比如推送这个动作，本质上是把本地分支的提交对象推送到远程仓库，并让远程分支指针也跟着走到相同位置。拉取操作则是先把本地提交搬到远程提交的后面，再走一次变基，让历史保持线性。

2.1 合并和变基的差别

这里要单独解释一下合并和变基，因为它是工作流设计中最容易让团队吵架的地方。合并会把两条分支的历史像麻花一样拧在一起，生成一个合并提交。这个提交有两个父亲，历史图谱会出现分叉。变基则会把当前分支上的提交一个个摘下来，再按照顺序重新播放到目标分支的顶端，形成一条直线。一个偏重“记录真实发生的事”，一个偏重“让过程看起来更干净”。

你可以自己动手试试，在终端里执行下面的命令感受区别：

# 技术栈：Git
# 先创建两个分支并制造分叉
git init demo-rebase
cd demo-rebase

# 在主分支上提交一次
echo "first" > a.txt
git add a.txt
git commit -m "chore: 初始化文件"

# 切出功能分支，加点内容
git switch -c feature/test
echo "feature" >> a.txt
git commit -am "feat: 增加功能内容"

# 切回主分支，再做一次提交
git switch main
echo "main update" >> a.txt
git commit -am "docs: 主分支更新"

# 用合并命令完成合并
git merge feature/test

执行完，你会看到分叉的图谱。如果把刚才的仓库删掉重来，最后一行改成变基合并，历史就是一条直线。需要说明的是，变基会重写提交的哈希值，所以已经推送到远程并把合并在公共分支上的提交，千万不要随便变基，否则大家会乱成一锅粥。

三、流程设计的核心要素

了解底层的零件之后，就可以开始设计属于团队的流程了。好的流程通常围绕三个核心要素展开：分支策略、提交规范、评审与合并策略。

3.1 分支策略

分支策略是工作流的地基。常见的做法是保留几个长期存在的分支：主分支作为生产分支，任何时刻这里的代码都应该是可发布的；开发分支作为集成分支，平时开发的新功能先汇合到这里；每个需求再从开发分支切出一个功能分支。修复线上问题则从主分支切出修复分支，修完后同时合并回主分支和开发分支，防止遗漏。

这种模型被称为“Git Flow”，很经典，但规则较重。如果团队小、发布节奏快，也可以简化成“GitHub Flow”：只有一个主分支，每次开发都从主分支拉新分支，完成后通过合并请求合回主分支。具体选哪种，要看你们的发布频率和团队成熟度。关键是大家要一致认可，然后写进代码仓库的说明文档里。

3.2 提交规范

提交信息不是用来给你自己看的，是给未来的同事、甚至半年后的自己看的。推荐使用“约定式提交”风格：一条提交信息分成类型、影响范围、简要描述。比如“功能类型加模块范围加一行说明”表示一个新功能；“修复类型加模块范围加一行说明”表示修复了一个问题。常用类型有功能、修复、文档、样式、重构、性能、测试、杂务。

用脚本来强制校验提交信息，可以在提交时就拦住不规范的信息，而不是等代码评审时被人指出。这个我们会在第四部分详细演示。除了格式，一个提交也要尽量保持逻辑上的“原子性”：一个提交最好只做一件事，不要把格式调整和功能修改混在一起，否则将来定位问题时很难办。

3.3 评审与合并策略

评审不是走过场，而是用一双新的眼睛，帮代码找找漏洞、看看设计是否合理。把评审嵌入流程，通常需要借助合并请求或拉取请求。开发者完成功能后，发起一个合并请求，指定几个同事作为评审人。评审人可以在代码行内留言，讨论清楚后再点通过。最后，合并方式可以选择普通合并、压缩合并或变基合并。

压缩合并会把分支上很多零碎的提交压成一个整洁的提交，适合功能分支；变基合并能让历史保持线性，但要求每个提交本身是可用的。这里要给团队定一个默认规则。我的建议是：功能分支合并到主分支时用压缩合并，长期分支之间用普通合并，避免重写公共历史。

四、用Git钩子实现自定义约束

分支和提交规范如果只是写在文档里，总有人会忘。Git 提供了一套“钩子”机制，能在特定事件发生前或发生后触发你写的脚本。常见的钩子有提交前、提交信息检查后、推送前、合并后等等。我们可以利用它们，把流程中的硬性规则变成自动检查。

钩子脚本放在每个仓库的隐藏目录下，默认有一些示例，但要自己新建。因为隐藏目录不会被提交，所以团队统一钩子需要额外的方案。推荐的做法是在项目根目录建一个专用目录，把脚本放入，然后用下面这条命令让当前仓库使用这个目录作为钩子来源。这个命令最好写进启动脚本或初始化脚本里，方便新人一键配置。

# 技术栈：Git
# 让当前仓库使用项目根目录下的 githooks 文件夹作为钩子目录
git config core.hooksPath githooks

4.1 用提交前钩子检查基础质量

提交前钩子在用户执行提交时运行，退出码不是零就会中断提交。我们可以用它做很多事情，比如检查是否不小心打印了调试语句、是否留下空白字符、是否提交了密钥文件。下面是一个简单的脚本，用于检查文件里是否有调试用的标记（假设团队用 JavaScript，但这里技术栈是 Git，只做文本检查，不依赖语言）：

#!/usr/bin/env bash
# 技术栈：Git（配合Shell脚本）
# 文件名：githooks/pre-commit
# 作用：在提交前检查暂存区里的文件是否包含调试标记

# 拿到暂存区中所有文件（排除删除项）
files=$(git diff --cached --name-only --diff-filter=ACM)

# 定义错误标记
has_error=0

for file in $files; do
    # 跳过不存在的文件
    if [[ ! -f "$file" ]]; then
        continue
    fi

    # 检查文件内容中是否出现 DEBUG_MARK 标记
    if grep -n "DEBUG_MARK" "$file" >/dev/null 2>&1; then
        echo "错误：$file 中出现了 DEBUG_MARK 标记，请删除后再提交" >&2
        has_error=1
    fi
done

# 如果有错误，退出码返回1，阻止提交
if [[ $has_error -ne 0 ]]; then
    exit 1
fi

exit 0

这个脚本的思路是：先拿到这次提交要处理的所有文件，然后逐个找标志字符串。找到就提示并退出。当然真实项目中可以换成代码检查工具，但在钩子里只要能调用得动，都是同样的思路。

4.2 用提交信息钩子校验提交信息

提交信息钩子会在用户写好提交信息之后被触发，参数是存放提交信息的临时文件路径。我们读出来，跟正则表达式比一比，不通过就退出。下面示例强制提交信息必须以几种指定类型开头，并且描述至少 5 个字符：

#!/usr/bin/env bash
# 技术栈：Git（配合Shell脚本）
# 文件名：githooks/commit-msg
# 作用：校验提交说明是否符合约定式提交规范

commit_msg_file=$1

# 读取使用者填写的提交信息
msg=$(cat "$commit_msg_file")

# 正则说明：
# ^(feat|fix|docs|...)：必须是这些类型之一
# (\(.+\))?：可选的模块范围，例如 (login)
# (:\s) ：类型和描述之间必须有冒号和空格
# .{5,}$：描述部分至少5个字符
pattern='^(feat|fix|docs|style|refactor|perf|test|chore)(\(.+\))?: .{5,}$'

if [[ ! "$msg" =~ $pattern ]]; then
    echo "提交信息不规范！请按照示例写：feat(login): 增加短信验证码" >&2
    echo "可选类型：feat, fix, docs, style, refactor, perf, test, chore" >&2
    exit 1
fi

exit 0

示例中的正则表达式已经覆盖了常见的提交类型，如果团队要支持更多类型，比如构建或持续集成相关的类型，直接加进括号即可。钩子生效后，团队成员再想随手写一个“update”或者“修复bug”就会被命令拦下来，大大减少垃圾提交信息。

4.3 用推送前钩子保护核心分支

推送前钩子会在推送命令执行之前触发，并且可以知道远程分支、本地分支等信息。我们可以用它禁止普通开发者直接往主分支推送代码，要求他们走合并请求流程。这样在代码评审环节之前，就从技术层面堵住了误操作。

#!/usr/bin/env bash
# 技术栈：Git（配合Shell脚本）
# 文件名：githooks/pre-push
# 作用：禁止直接推送代码到主分支

# 推送前钩子接收远程名称作为第一个参数
remote="$1"
shift

# 标准输入格式为：本地引用 本地哈希 远程引用 远程哈希
while read local_ref local_sha remote_ref remote_sha; do
    # 提取远程分支的名字，例如 refs/heads/main -> main
    remote_branch=${remote_ref#refs/heads/}

    # 如果是主分支，拒绝推送
    if [[ "$remote_branch" == "main" || "$remote_branch" == "master" ]]; then
        echo "禁止直接推送代码到 $remote_branch 分支！" >&2
        echo "请先创建功能分支，提交并推送后发起合并请求。" >&2
        exit 1
    fi
done

exit 0

这里利用推送命令传给脚本的数据格式：每一行包含本地引用、本地哈希、远程引用、远程哈希。我们逐行找出远程分支名，如果是主分支，就给用户一个明确提示并拒绝此次推送。这个钩子并不能替代服务端的分支保护，但能给开发者提供第一道防线。

五、结合平台设置保护分支

光有本地钩子还不够，因为钩子只在开发者自己电脑上生效，一个人没装钩子或者绕过钩子，照样可能推上去。真正的兜底，是在代码托管平台的服务器端开启分支保护。无论你用的是 GitHub、GitLab 还是 Gitee，大部分平台都提供“受保护分支”功能。在平台设置中将主分支和开发分支设置为受保护分支之后，普通成员就不能直接推送或强制推送，只能通过合并请求。即使是管理员，也会被限制强制推送，避免历史被意外改写。

这些平台操作虽然是用鼠标点，但背后其实就是给远程仓库设置了一些权限规则。我们可以在项目中写一个文档，记录下保护分支的配置规则，方便团队参照。实际落地以平台的 Web 配置为准。

5.1 把钩子和平台保护串起来

本地钩子负责“提醒”，平台保护负责“强制”。举个例子：某成员想直接推送修复到主分支，本地推送前钩子立刻报错，他只能乖乖转向合并请求。如果他强制跳过本地钩子直接推送，服务端分支保护又会拒绝。两道防线互相补位，流程才能真正稳定下来。

六、一个完整的团队协作流程适配示例

下面用一个具体的需求场景，把整个流程串起来。假设我们现在要开发一个“优惠券”功能，团队有 3 个人，开发完成后需要评审再发布。

第一步，从最新开发分支拉出功能分支：

# 技术栈：Git
# 确保本地开发分支是最新的
git switch develop
git pull --rebase origin develop

# 基于最新开发分支创建功能分支
git switch -c feature/coupon

第二步，在功能分支上修改代码，并用前文提到的钩子检查。假设我们修改了一个文件，提交时命令如下：

# 技术栈：Git
# 添加所有修改并提交
git add coupon.js
git commit -m "feat(coupon): 新增优惠券领取与核销流程"

如果提交信息写得不规范，提交信息钩子会给出提示，要求重写。如果没有钩子，这一步往往会被跳过。提交成功后，我们继续完成开发，然后把分支推送到远程：

# 技术栈：Git
# 推送功能分支到远程仓库
git push -u origin feature/coupon

第三步，发起合并请求。这一步通常在浏览器里操作，但也可以用命令行工具或平台 API。我们仍然用一条命令查看当前分支与开发分支的差异，确认没有多余提交：

# 技术栈：Git
# 查看 feature/coupon 比 develop 多出的提交
git log --oneline develop..feature/coupon

评审人在页面里看到差异后，可以留下意见。开发者根据意见修改，再追加提交并推送，评审通过后，由负责人点击“合并”。合并时如果选择了压缩合并，所有的提交会收成一个提交，历史非常整洁。

第四步，发布上线。上线完成后，我们创建一个发布分支，经过验证后合并到主分支，并打上标签：

# 技术栈：Git
# 创建发布分支并合并到主分支
git switch -c release/1.2.0

# 在发布分支上验证...
git switch main
git pull --rebase origin main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "发布优惠券功能"
git push origin main --tags

这里用了强制创建合并提交的选项，目的是在主分支的历史上清晰标记出一次发布。团队可以把这个发布流程沉淀成脚本，进一步减少手工操作的失误。

七、应用场景、优缺点与注意事项

7.1 适合哪些场景

这种自定义工作流最匹配十几人到几十人的研发团队，尤其是需要同时维护多个线上版本、有固定发版节奏、并且有代码评审制度的团队。如果只是个人项目或者两三个人的小实验，规则太细反而拖慢速度。另外，强制提交规范对开源社区非常友好，可以让不同时区、不同背景的协作者有一种统一的沟通语言。

7.2 优点与缺点

优点很明显：历史清晰，定位问题方便；分支命名统一，自动化脚本好识别；钩子在开发端拦下大量低级错误；平台保护又兜住了高级风险；团队新成员不用问东问西，照着工作流文档做就行。

缺点也不可忽视。钩子脚本需要维护，如果写得有 bug，会卡住所有开发者的正常工作。提交规范太严的话，开发者会频繁被打断，产生厌倦情绪。分支模型如果太复杂，小团队会感觉很重，每天都在切分支、解决冲突。这些都是设计时需要权衡的。

7.3 注意事项

首先，钩子脚本要尽量短小、易读，别把复杂的业务逻辑塞进去。其次，所有自定义脚本必须通过版本控制来管理，并放在仓库的专用目录中，用一条仓库配置统一指向这个目录。第三，不要在 主分支 上做太严的拦截，要给开发者一些临时实验的空间。第四，平台分支保护规则要定期复盘，随着团队规模调整评审人数和强制检查项。最后，工作流不是靠“压”的，要通过文档和演示让团队成员看到流程带来的好处，例如减少上线事故、节省排查时间。如果大家对规则不理解，再好的脚本也会被吐槽。

八、总结

Git 本身并不规定团队应该怎么工作，它提供的是分支、提交、合并、钩子这些基础零件。自定义工作流的设计过程，其实就是结合团队现状，把这些零件拼成一条顺手的流水线。先想清楚分支怎么分、提交怎么写、评审怎么过，再用钩子和平台保护把硬规则落地。这套方案没有唯一标准答案，和团队的规模、发布节奏、人员习惯都有关系。关键是保持“够用”和“迭代”的心态：先解决最痛的问题，再慢慢优化流程，让团队在协作中持续感受到秩序带来的轻松感。把规则变成工具，把工具融入日常，Git 就能从麻烦制造者变成真正可靠的帮手。