Git分支管理实践

Git分支管理真的是因人而异，因团队而异，因项目而异。今天分享一个Git分支管理的工作流程，或许你的团队也会有不一样的分支管理最佳实践，可以在评论区交流一下呀。

正片开始

在日常开发中，我们一般维护三个分支：release、develop、feature。

release分支用于预发、生产环境的代码部署，其要求已测试通过、功能稳定、运行无异常，开发不会频繁更新。

develop分支用于开发环境的代码部署，其功能处于测试阶段，还不具备上线要求，开发会频繁更新，该分支主要用于测试在开发环境测试使用。

对于开发来说，需求的开发迭代需要基于develop分支，拉取一个自己的feature，命名为feature/时间_需求的简单描述，开发基于该分支做需求开发、调试，最后新需求开发完毕了，再将feature分支合并到develop分支进行提测。

release分支的管理，该分支的代码基本都是通过其他分支merge进来的，一般会有以下几种场景

1. 无并发需求时，feature分支代码已经在develop分支上测试通过，那么可以把develop分支代码合并到release分支
2. 存在并发需求时，feature分支代码已经在develop分支上测试通过，因为存在并发需求，develop上的代码还不稳定，不能直接合并到release分支，此时就可以把feature分支代码合并到release分支

要完成上述的分支管理，我们需要知道以下两点：

1. 创建新分支（基于develop分支，创建一个feature）
2. 分支合并（把feature分支开发的代码合并到develop分支）

这两点我将会在后面的文章中介绍。

如何理解下面的问题

1. 并发需求

所谓的并发需求就是两个同时开发的需求。

比如，一个开发小组在某一个时间段（本月 1 号），使用同一个代码分支，同时开发两个需求 A、B。

如果需求 A 先开发完了（本月 5 号开发完毕），合并到develop分支进行提测，提测预计花费 3 天，要 8 号才能测完。需求 B 开发的稍微慢一些，本月 7 号开发完毕，开发完毕了也进行了提测，提测预计花费 4 天，要 11 号才能测完。

需求测试完，就可以把代码合并到release分支上生产环境。

此时，如果需求 B 在 8 号测试完了，其要上生产，是不能直接把develop分支的代码合并到release分支的。因为此时需求 A 的代码也在develop分支上，并且是没有测试完的。

因此，对于需求 A 的代码如何进release分支，只能通过把feature分支合并release分支来完成。

如果说不存在并发需求。即在一个时间段内需求 A、B 都测试完了，要一起上生产，那么直接把develop分支代码合并到release分支即可。