常见的git工作流汇总
| 序号 | 名称 | 特点 |
|---|---|---|
| 1 | Git Flow | 最早诞生并得到广泛使用，拥有master和develop两个长期分支，流程规范，版本管理清晰 |
| 2 | GitHub Flow | 主要涉及主分支和一个用于特性开发的分支，适合用于持续集成和持续部署 |
| 3 | GitLab Flow | 结合了GitHub Flow的简单性和Git Flow的稳定性，同时支持环境分支和版本发布 |
1.Git Flow
最早诞生、并得到广泛采用的一种工作流程，就是Git Flow。Git Flow有两个长期分支，master和delevop分支
Git Flow的分支划分
- master (主分支)： 存放随时可供在生产环境中部署的代码
- develop （开发分支）：所有开发活动都在develop分支上进行，确保主分支上的所有内容都是随时可发布的
- feature （特性分支）：从develop分支分出，特性分支完成后，将合并回develop分支，等待下一次发布周期。
- release （发布分支）：从develop分支分出，准备发布新版本时，会创建一个发布分支。在这个分支上，团队可以进行最后的调整，如bug修复、文档编写等。
- hotfix （修复分支）：从master分支分出，用于紧急修复线上问题。修复完成后，分支会被合并回master和develop分支
从上面的分支功能划分可以看出，master和develop的两个最重要的分支，其他的将从这两个分支中迁出或者合入。
Git Flow的工作流程
开发流程
1. 从develop分支创建feature分支
- 每个新的功能都应该在独立的feature分支上开发
- 开发完成后，将feature分支合并回develop分支
2. 从develop分支创建release分支
- 当开发阶段完成，准备发布新版本时，从develop分支创建一个release分支
- 在release分支上进行最后的测试和修复
3. 将release分支分别合并到master分支和develop分支
- 完成测试后，将release分支合并到master分支，生成一个新的tag,表示一个新的发布版本
- 同时，将release分支合并回delevop分支，将发布的内容合并到下一个开发版本中
修复流程
1. 从master分支创建hotfix分支
当生产环境出现紧急bug时，从master分支上对象的tag创建一个hotfix分支
2. 将hotfix分支合并回master分支和develop分支
修复bug后，将hotfix分支分别合并回master分支和develop分支
Git Flow的优缺点
优点： 适合有固定发布周期的项目，流程规范，版本管理清晰。
缺点： 流程较为复杂，对于小型项目可能过于繁琐。
2.Github Flow
Github Flow是Git flow的简化版，专门配合“持续发布”，它是github.com使用的工作流程。它只有一个长期分支，那就是master。
Github Flow的工作流程
1. 创建新分支
需要添加新功能、bug修复或者进行任何修改时，从主分支创建出新分支，新分支主要用于隔离开发工作。
2. 新分支添加提交
在新分支上进行开发工作，频繁地添加提交以记录所做的更改。这些提交应该尽可能小且具有描述性，以便于其他开发者理解和审查。
3. 发起Pull Request
当更改准备好进行审查是，通过github发起一个Pull Request(PR)。这会自动启动代码审查流程，其他开发者可以查看代码并提出建议或反馈。
4. 讨论和审查
在Pull Request中，团队成员可以对代码进行讨论和审查，这可能包括代码风格、功能实现、测试覆盖等方面的反馈。
5. 更新代码
根据审查意见，你可能会需要更新你的代码。继续在新分支上添加提交，这些提交会自动添加到Pull Request中。
6. 合并到主分支
一旦代码审查通过，并且所有相关方都同意合并，新分支的更改内容就会被合并到主分支。某些情况下，可能要满足特定的条件，比如所有审查者都批准，或者所有持续集成测试都通过。
7. 部署
主分支的更改通常会被自动部署到生产环境，或者至少部署到一个可以进一步测试的环境。
Github Flow的优缺点
优点： 流程简单，适合快速迭代的项目。
缺点： 缺乏对发布版本的严格管理。
3.GitLab Flow
GitLab Flow 是 GitLab 推荐的一种工作流程，它结合了 Git Flow 和 GitHub Flow 的优点，旨在提供一种适用于多种项目类型和团队的灵活的版本控制策略。GitLab Flow 支持不同的分支策略，具体取决于项目的发布周期和部署环境。
GitLab Flow分支划分参考
在 GitLab Flow 中，并没有严格的分支命名规则，但以下是一些常见的分支命名约定：
主分支：
master：这是默认的主分支，用于存放随时可供生产部署的代码。
环境分支：
production：用于生产环境的代码。
staging：用于预生产环境的代码。
test：用于测试环境的代码。
uat：用于用户测试验收。
development：用于开发环境的代码。
特性分支：
feature/feature-name：用于开发新功能的分支，例如 feature/new-login.
feat/feature-name：另一种命名特性分支的方式。
修复分支：
bugfix/bug-name：用于修复特定bug的分支，例如 bugfix/login-issue.
fix/bug-name：另一种命名修复分支的方式。
发布分支：
release/x.y.z：用于准备新版本发布的分支，其中 x.y.z 是即将发布的版本号，例如 release/1.2.3.
维护分支：
hotfix/x.y.z：用于紧急修复生产环境问题的分支，其中 x.y.z 是受影响的版本号，例如 hotfix/1.2.3.
实验性分支：
experiment/experiment-name：用于尝试新想法或技术的分支，这些分支可能不会合并到主分支。
GitLab Flow的工作流程(参考)
GitLab Flow的优缺点
优点
灵活可定制： GitLab Flow 没有非常严格的规定，可以根据团队和项目的实际情况进行调整，适应性强。
频繁提交： 鼓励开发者频繁提交代码，保持主分支的活跃，有利于及时发现问题。
自动化部署： 可以很好地与 CI/CD 集成，实现自动化部署，加快发布速度。
环境隔离： 通过多个分支隔离不同的环境，降低部署风险。
简单易懂： 相较于 Git Flow，GitLab Flow 的流程更简单易懂，更容易被团队成员接受。
缺点
缺乏严格的规范： 由于灵活性高，可能导致团队成员在分支管理上出现不一致，需要制定明确的规范。
分支过多可能导致混乱： 如果项目规模较大，分支数量过多，可能会增加管理难度。
对 CI/CD 的依赖性强： GitLab Flow 依赖于 CI/CD pipeline 实现自动化部署，如果 CI/CD 配置不当，可能会影响发布流程。
总结
本文介绍了三种git的开发工作流程(Git Flow、GitHub Flow、GitLab Flow)，其中GitLab Flow结合了 Git Flow 和 GitHub Flow 的优点,它兼顾了快速迭代和质量保证。但是，并不是所有的项目都适合 GitLab Flow，在选择工作流时，需要综合考虑团队规模、项目复杂度、发布频率等因素。