这是《重学Git》专栏的第一篇文章，想了很久不知道该以什么样的形式开始介绍这个章节。

像有一些Git教程一样，从零到一为大家介绍Git是什么，Git怎么用，好像也行，但是我不是特别喜欢这样，不想趋同，或者说既然市面上已经有相关的教程了，大家完全可以直接去学习其他教程，其他教程写的也很好。

我更想从一些我们习以为常的工作开始讲起和读者一起思考、探索我们正在做的事是否合理，或者说，通过阅读这篇文章也会引起你的一些思考。

正片开始

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

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

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

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

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

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

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

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

如何理解下面的问题

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

比如，一个开发小组在某一个时间段（本月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分支即可。