GitFlow工作流

最新推荐文章于 2025-03-06 15:00:19 发布

这孩子叫逆

最新推荐文章于 2025-03-06 15:00:19 发布

阅读量1k

点赞数 8

分类专栏： git 文章标签： git

本文链接：https://blog.youkuaiyun.com/zhzjn/article/details/142925009

版权

git 专栏收录该内容

8 篇文章

订阅专栏

GitFlow是一种为Git版本控制系统设计的分支管理工作流，由Vincent Driessen在2010年提出。这种工作流旨在帮助团队更有效地管理软件开发过程中的不同阶段，如新功能开发、版本发布、热修复以及维护，通过定义一套清晰的分支规则和角色来维持代码库的整洁和项目的可维护性。

1.常规分支-master&develop

master主分支（现在更常被称为 main 分支）储存正式发布的历史，develop开发分支作为功能开发集成分支。

master：这个分支代表了随时可以部署到生产环境的代码状态，也就是项目的最新稳定版本。

develop作为日常开发的基础分支，用于整合所有即将发布的新功能和改进。它是开发团队合作的主要分支。

2.功能分支-feature

feature 分支是在Git版本控制系统中使用的一种开发分支，专注于单一功能，每个 feature 分支都对应着要实现的一个具体功能或者改进点。这样做的目的是保持每次改动的范围清晰、易于管理和审查。但功能分支不是从master分支上拉出来的新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。新功能的提交不直接与master交互。

3.发布分支-release

release 分支在Git版本控制系统中是用来准备新版本发布的专用分支。它介于开发分支（如 develop）和主分支（如 main 或 master）之间，扮演着承上启下的角色，确保即将发布到生产环境的代码是经过充分测试和稳定的。

一旦develop分支上的功能到了发布日期，就从develop分支fork一个发布分支（一般叫release）。release分支用于预发布测试，所以从这个时间点开始后新的功能不再加到这个分支上，release分支只应该做全面测试、bug修复。一旦release测试完毕并准备发布后，将其合并到master分支并分配一个版本号打上Tag。另外，release上做的bug修改要合并回develop分支。

使用场景：

创建分支： 当项目团队决定为下一次发布做准备时，从 develop 分支创建一个 release 分支，比如 release/v1.0.0。
测试与修复： 在 release 分支上进行全面的测试，修复发现的问题，并将修复提交到此分支。
冻结功能添加： 一旦创建了 release 分支，原则上不再向其添加新的功能，仅接受bug修复和必要的调整。
合并到主分支与打标签： 经过充分测试确认无误后，将 release 分支合并到 main/master 分支，并在合并提交上打上版本标签（如 v1.0.0），标志着正式发布。
合并回 develop： 发布完成后，通常还会将 release 分支合并回 develop 分支，确保 develop 包含了所有已经发布的内容，为下一个开发周期做准备。

4.维护分支-hotfix

维护分支（一般叫hotfix）是唯一可以直接从master分支fork出来的特殊分支，用于快速修复生产环境中发现的紧急问题的分支。修复完成后，应马上合并回master和develop分支，同时master分支用新版本号打上Tag。

使用场景：

发现问题： 生产环境中发现紧急问题或收到用户报告的重大故障。
创建分支： 从 main/master 分支创建一个 hotfix 分支，例如 hotfix/issue-1234，其中 issue-1234 是对问题的简要描述或追踪ID。
实施修复： 在 hotfix 分支上进行问题的诊断和修复，可能包括编写测试用例以验证修复的有效性。
测试： 尽管时间紧迫，但对 hotfix 的测试仍然至关重要，确保修复没有引入新的问题。
合并到 main/master： 修复验证无误后，将 hotfix 分支合并回 main/master，并尽快部署到生产环境。
合并到 develop： 随后，将 hotfix 分支的改动合并到 develop 分支，以确保开发中的版本也包含了这个修复，防止问题重现。