前言

近期因多项目同时开发，且各个项目的上线周期可能存在冲突和重叠，在代码管理上出现了一些问题。

为减少这些问题带来的不必要的麻烦，网关组自行约定了代码管理方法，并试用。

分支命名

master（预发和生产版本）：核心分支，主分支，随时可供在生产环境中部署的代码；
dev（开发环境版本）：保存当前稳定并且最新的开发分支，有开发人员进行自测，稳定后检出release；
release（测试环境版本）：dev测试稳定后，从dev检出（此时dev可服务于其他测试内容），release版本提交测试进行测试，允许代码微调，修改后需合并回dev和master；
命名规则：release_检出日期_开发人员_功能简述，例如：release_20180301_zhangsan_recode；
feature（本地或开发版本）：新功能开发，开发过程中的分支，从dev分支检出，命名规则：feature_检出日期_开发人员_功能简述；
例如：feature_20180301_zhangsan_recode
hotfix（测试、预发和生产版本）：线上紧急问题修复的分支，直接从master检出，可用直接上线，上线完成后需要合并到master，并从master检出tag；
命名规则：hotfix_检出日期_开发人员_修复问题简述，例如：hotfix_20180303_lisi_qpay
tag（留存上线版本）：标签，当有重要功能或问题上线后，从master检出，用于记录；
命名规则：tag_版本号_检出日期_内容，例如：tag_v1.0.1_20180303_qpay
bugfix（本地或开发版本）：发现不紧急的bug时，可以从dev分支检出bugfix分支，修复自测后，合并回dev分支，不受项目限制；
命名规则：bugfix_检出日期_开发人员_修复问题简述，例如：bugfix_20180303_lisi_qpay

项目测试

项目分支开发完成后，将代码从开发分支合并到dev分支，并由开发人员在开发环境进行自测；
如dev分支已存在其他未上线代码，且未打release分支，则可根据情况暂缓合并；
如项目1和项目2（或多个项目）准备同时上线，则可将两个或多个项目都合并到dev，并解决相应的冲突，自测完毕后，检出release分支，提交release分支给测试人员；
如release版本在测试期间发现bug或其他小的变动，直接从release分支修改（必要时需要merge一下dev分支），完成后合并到dev、master分支；
如不确定的修复方案可在原分支进行修改，在不影响其他项目的情况下不需要回滚dev，如有影响，则需要回滚dev分支；
项目测试稳定后，将release分支和并到master，并在master进行回归测试；

项目上线

项目测试完成后，从release分支合并到master进行回归测试，如果回归测试时发现问题，需在release进行微调，并合并回dev和master；
如若发现合并master时存在更新，需及时检查问题，并在master进行回归测试；
上线完成后，从master检出tag，用来保存当时上线的版本号；

分支清理

随着新项目的增多，代码库中存在的分支或标签会越来越多，需要定期清理；

清理办法：

清理频率：每三个月清理一次；
清理内容：三个月前的代码，含branch项目开发分支、bugfix问题修复和tag标签；
清理规则：
feature_* 分支直接删除；
release_* 分支，直接删除；
bugfix_* 分支，在清理日志中记录版本号和修复问题后删除；
hotfix_* 分支，在清理日志中记录版本号和修复问题后删除；
tag_* 分支，在清理日志中记录版本号和标签内容后删除；

删除远程分支：

git branch -r -D origin/mgs_branch_20171208

git push origin :mgs_branch_20171208

删除本地分支：

git branch -D mgs_branch_20171208

注意事项

要求dev分支，在打出release分支前，只保证一个项目存在。如多个项目可合并测试上线，可保持多个。
对于不紧急的bug，可从dev检出bugfix分支，开发自测完成后合并到dev，随下个版本上线（需测试）；
如在dev未测试完成前（即还没有完全稳定），此时检出的feature分支，需要随时和dev分支保持同步；
开发的feature尽可能地跟dev保持同步；

Git代码开发分支管理办法

前言

分支命名

项目测试

项目上线

分支清理

注意事项

图像描述

参考地址

猜你喜欢