企业级git协同开发流程

随着企业规模的扩大，同一个项目可能由多个开发人员进行开发，所以我们需要使用git来进行协同开发，为了保证线上程序的稳定，以及规范开发流程。我们需要使用git的多分支来保证我们发布项目的时序问题

使用多分支能够解决的问题

1 假设A开发A功能，B开发B功能，开发完成后，都推送到master分支去等待测试，然而完成项目发布需要等待AB功能同时通过后才能发布master分支代码。这样会照成部分功能不能单独上线的问题。

2 大家都使用master分支去做开发的话。会照成代码冲突的情况，理论上我们开发的环境是相互独立的，我的开发不会影响你的开发。如果同一个功能，我们就在同一个分支下面去做开发

需要创建的分支

• 主分支（master）

master 分支保存的是稳定的已发布到线上的代码，会使用 tag 来记录发布的重要节点的版本（tag命名为：tag-版本号）。master 分支不允许提交代码，只能将代码合并（merge）到 master。
正式环境的代码以master分支的代码为准。在蓝绿部署的情况下，绿色部署环境需要部署此分支代码。

• 开发分支（develop)

开发分支，从 master 创建。需要注意的是，develop分支的代码是通过feature分支合并而来的。通常情况下我们是不会在 develop 上开发的，因为你不能确定这些是否需要上线（或者说无法确定在哪次迭代上线）。
develop分支上的代码都是即将发布到预发布分支上的。不确定是否要发布的代码不要合并到develop。

• 功能分支（feature_xx)

功能分支，从 develop 或 master创建，存在版本号。feature 分支是用来开发新功能的，通常情况下新功能开发完毕后会合并的 develop。
协同开发同一个新功能的伙伴，都在同一个feature_xx分支下开发。

• 修复分支（hotfix_xx）

修复分支，从 master 创建或拉取，存在版本号hotfix_缺陷管理bug号_Date。当我们发现线上 Bug 时，会从 master 分支上对应的 tag 处创建新的 hotfix 分支，用来修复 bug。通常情况下，紧急修复的发布相对简单，在 Bug 修复并测试完成后，可直接合并到 master 进行发布（注意：如果在蓝绿部署的情况下，需要将bug修复之后的代码重新打包，并部署到蓝色环境下等待测试通过后，再将代码合并到master上）。发布完成后在 master打上 tag 记录此次发布的版本，并将 hotfix 合并到 develop。

• 预发布分支（release_xx）

预发布分支 从 develop 创建，存在版本号，版本号跟feature分支保持一致。当一次迭代的功能开发并自测完成后，就可以创建预发布分支。该分支通常用于测试，我们不能在该分支上完成除Bug 修复外的其他工作。测试完成后，我们需要将 release 分支合并到 master 进行发布。发布完成后在 master 打上 tag 记录此次发布的版本。在蓝绿部署的情况下，蓝色部署环境需要部署此分支代码。
该分支通常用于测试。

主要分为上述分支，这样就可以对项目全流程进行把控，不同功能不会相互影响上线。