代码托管 CODEARTS REPO-分支管理:基于Git分支的经典工作模式
基于Git分支的经典工作模式
在基于分支的代码管理工作模式中,“Git-Flow”在业界被更多人认可,同时也被广泛应用,如果您的团队目前还没有更好的工作模式,可以先从尝试使用“Git-Flow”开始。
- 并行开发:支持多个特性与bug修复并行开发,因其可以同时在不同分支中进行,所以在代码写作时互不受影响。
- 团队协作:多人开发过程中,每条分支(可以理解为每个子团队)的开发内容可以被单独记录、合并到项目版本中,当出现问题时还可被精确检出并单独修改而不影响主版本的其它代码。
- 灵活调整:通过HotFix分支的使用,支持各种紧急修复的情况,而不会对主版本以及各个团队的子项目产生干扰影响。
分支名 |
Master |
Develop |
Feature_1\2... |
Release |
HotFix_1\2... |
---|---|---|---|---|---|
说明 |
核心分支,配合标签,用于归档历史版本,要保证其中的版本都是可用的。 |
开发主分支,用于平时开发的主分支,应永远是功能最新最全的分支。 |
新特性开发分支,用于开发某个新特性,可以几条并行存在,每条对应一个或一组新特性。 |
发布分支,用于检出某个要发布的版本。 |
快速修复分支,用于当现网版本发现bug时,拉出来单独用于修复这些bug的分支。 |
有效性 |
长期存在 |
长期存在 |
临时 |
长期存在 |
临时 |
何时被创建 |
项目仓库建立之初 |
在master分支被创建之后 |
|
项目首次发布前,基于develop分支创建 |
当master、bug版本中发现问题时,基于对应版本(一般是master分支)创建 |
何时直接在此分支上开发 |
从不 |
一般不建议 |
当被创建出来,开始开发新特性时 |
从不 |
当被建立出来时 |
何时被其它分支合入 |
|
|
子feature分支开发、测试完成后,会合入到父feature分支 |
当需要发布一个版本时,被develop分支合入 |
- |
何时合入到其它分支 |
- |
|
当该分支上的新特性开发、测试完成时,合入到develop分支 |
|
当其对应的bug修复任务完成时,会将其作为修复补丁合入master、develop分支 |
何时结束生命周期 |
- |
- |
其对应的特性已经验收(发布、稳定)后 |
- |
其对应的bug修复,已经验收(发布、稳定)后 |
另外在使用Git-Flow工作模式时,业界普遍遵循如下规则:
- 所有开发分支从develop分支拉取。
- 所有hotfix分支从master分支拉取。
- 所有在master分支上的提交都必须要有标签,方便回滚。
- 只要有合并到master分支的操作,都需要和develop分支合并,保证同步。
- master分支和develop分支是主要分支,并且都是唯一的,其它派生分支每个类型可以同时存在多个。