Git 分支管理策略

Git 分支管理策略

远程分支

master 分支

Release 版本 - 包含线上已发布代码。master 分支的代码只允许从 pre_release分支进行merge

pre_release 分支

预发布版本 - 发布到测试环境，用于产品 & 测试人员进行功能性测试。
包含本次 Release 时，预上线的所有功能。

Note：禁止提交任何正在开发中 & 不准备上线的功能代码。

dev 分支 - 此分支策略仅供参考

方案1：

Dev 版本 - 发布代码到开发公用的测试服务器，当开发的功能需要多个 Developer 协作完成时，可以把代码提交到 dev 分支。

dev 分支的代码，只需要在 push 前，保证代码的正确性即可（不要让其他人在检出项目后报错）。

方案2：

Dev版本 - 每个人新建自己的分支 dev_xxx（xxx 为开发人员自己的名字缩写）& push 到远程仓库。

主要用于保存本地代码在远程服务器的备份，防止开发工作丢失。

本地分支

feature-xxx - 功能性开发分支

Developer 在接到新需求时，可在本地自建 feature-xxx 分支。

在开发过程中，如果有需要，可以将代码 push 到 dev 分支，进行多人协作。

在功能开发完成后，

• 如果预期发布，则将本地的此分支代码 merge 到 pre_release 分支 & push。
• 如果不准备发布，则将本地的此分支代码保留。

bug-xxx - Bug 分支

在修复 Bug 时，

• 如果 Bug 不着急 & 很好修复, 直接在 pre_release 分支修正后 push 到远程仓库即可。
• 如果 Bug 不着急 & 很难修复，可能会影响到版本的发布，则在本地新建分支 bug-xxx ，修复完成后，根据是否需要在下次发版时修复此 bug 来决定是否推送到 pre_release 分支
• 如果 Bug 是从线上环境发现，并需要立即解决。则：
  1. 从 master 分支新建分支 bug-xxx， 修正完成后，直接 push 到远程仓库，然后由项目负责人进行合并处理 & 发布上线
  2. 同时还需要把 bug-xxx 分支 merge 到 pre_release 分支 & push