Git工作流程

作者：James Zhu ([email protected])

创建日期：2018-10-26

需求简述

将Git与工作流程结合起来，完善从开发、测试、审核、发布的整个流程，实现持续集成（Continuous Integration ）、持续发布（Continuous Delivery）。

Git项目生命周期

正如需求所提，整个工作流是围绕着Git所展开的，因此需要先定义清楚Git的工作流程，然后再通过其它工具辅助实现。

这个图和网上常见的Git Flow流程图类似，只是在发布的时候略去了release分支，以及合并master的来源分支。首先对这些分支逐一说明：

master分支

• 生产环境
• Protected
• Allowed to merge: Masters
• Allowed to push: No one
• Custom Git Hook (optional)

develop分支

• 集成测试环境
• Protected
• Allowed to merge: Developers + Maintainers
• Allowed to push: No one
• Custom Git Hook

feature/* 和 hotfix/* 分支

• 开发环境
• Unprotected

Q&A

Q: 既然所有人都可以审核develop分支的Merge Request，为什么还有有审核这个步骤呢？

A: 因为上线时从feature发起的，因此直接在develop进行的提交无法通过本流程发布，所以不允许直接修改develop，要通过feature走。

理论上来说，develop分支是一个与master保持一致的分支，只是合并的时间点不同。

Q: 为什么上线要从feature发起？

A: 因为每个项目的起止日期不同，很可能develop上同时包含了多个项目的分支，有的需要发布，有的还在测试。因此不能直接从develop合并master。

feature直接合并master后，在GitLab的分支后会有 已合并 的标记，也比较好区分该功能是否已经上线。

Q: 我的GitLab里为什么只有一个 Developers can push 的复选框？没有看见 Allowed to push 和 Allowed to merge 的选项。

A: Allowed to push 和 Allowed to merge 要求GitLab版本至少是8.11，请升级 itLab。

外部资源

• Web Sequence Diagrams

title Git项目生命周期

note left of feature1,feature2: 项目开始
note over develop,master: 受保护
master->develop: 初始化
master->feature2: 创建新功能分支
loop 开发
    feature2->feature2: 开发
end
note over feature2: 开发完成
feature2->develop: 代码合并
note over develop: 部署到sit
loop 测试
    note left of develop: 发现BUG
    feature2->develop: 修复BUG
end
note over develop: 测试完成
master->feature1: 创建新功能分支
loop 开发测试
    feature1->feature1: 开发测试
    feature1->develop: 代码合并
end
opt 上线合并请求
    feature1->+master: 代码审核通过
    master-->-feature1: 审核驳回
    note over master: 部署到生产（可选）
    feature2->+master: 代码审核通过
    master-->-feature2: 审核驳回
end
note over master: 部署到生产
note right of master: 发现线上BUG
master->hotfix: 创建补丁分支
loop 开发
    hotfix->hotfix: 修复BUG
end
opt BUG修复合并请求
    hotfix->+master: 代码审核通过
    master-->-hotfix: 审核驳回
end
hotfix->develop: 代码合并