华为云首页用户手册

代码托管 CODEARTS REPO-分支管理:基于Git分支的经典工作模式

代码托管 CODEARTS REPO-分支管理:基于Git分支的经典工作模式

时间：2023-12-06 10:17:44

代码托管 CODEARTS REPO 管理代码文件

基于Git分支的经典工作模式

在基于分支的代码管理工作模式中，“Git-Flow”在业界被更多人认可，同时也被广泛应用，如果您的团队目前还没有更好的工作模式，可以先从尝试使用“Git-Flow”开始。

Git-Flow是一种基于Git的代码管理工作模式，它提供了一组分支使用建议，可以帮助团队提高效率、减少代码冲突，其具备以下特性。

并行开发：支持多个特性与bug修复并行开发，因其可以同时在不同分支中进行，所以在代码写作时互不受影响。
团队协作：多人开发过程中，每条分支（可以理解为每个子团队）的开发内容可以被单独记录、合并到项目版本中，当出现问题时还可被精确检出并单独修改而不影响主版本的其它代码。
灵活调整：通过HotFix分支的使用，支持各种紧急修复的情况，而不会对主版本以及各个团队的子项目产生干扰影响。

表1 Git-Flow工作模式中分支的使用建议
分支名	Master	Develop	Feature_1\2...	Release	HotFix_1\2...
说明	核心分支，配合标签，用于归档历史版本，要保证其中的版本都是可用的。	开发主分支，用于平时开发的主分支，应永远是功能最新最全的分支。	新特性开发分支，用于开发某个新特性，可以几条并行存在，每条对应一个或一组新特性。	发布分支，用于检出某个要发布的版本。	快速修复分支，用于当现网版本发现bug时，拉出来单独用于修复这些bug的分支。
有效性	长期存在	长期存在	临时	长期存在	临时
何时被创建	项目仓库建立之初	在master分支被创建之后	收到新特性任务时，基于develop分支创建当正在开发的新特性任务被拆分成出子任务时，基于对应的父feature分支创建	项目首次发布前，基于develop分支创建	当master、bug版本中发现问题时，基于对应版本（一般是master分支）创建
何时直接在此分支上开发	从不	一般不建议	当被创建出来，开始开发新特性时	从不	当被建立出来时
何时被其它分支合入	项目版本封版时，被develop或release分支合入已发布版本中发现的bug被修复后，被对应的hotfix分支合入	新特性开发完成后，feature分支合入到此分支当项目启动开发一个新版本时，被上一次历史发布版本（release、或master）合入	子feature分支开发、测试完成后，会合入到父feature分支	当需要发布一个版本时，被develop分支合入	-
何时合入到其它分支	-	当要发布版本时，合入到release分支当需要归档版本时合入到master分支	当该分支上的新特性开发、测试完成时，合入到develop分支	当完成一次版本发布，将该版本归档时，合入到master分支当要基于某一个发布版本，开始开发一个新版本时，合入到develop分支，起到初始化版本的作用	当其对应的bug修复任务完成时，会将其作为修复补丁合入master、develop分支
何时结束生命周期	-	-	其对应的特性已经验收(发布、稳定)后	-	其对应的bug修复，已经验收(发布、稳定)后

另外在使用Git-Flow工作模式时，业界普遍遵循如下规则：

所有开发分支从develop分支拉取。
所有hotfix分支从master分支拉取。
所有在master分支上的提交都必须要有标签，方便回滚。
只要有合并到master分支的操作，都需要和develop分支合并，保证同步。
master分支和develop分支是主要分支，并且都是唯一的，其它派生分支每个类型可以同时存在多个。

上一篇：代码托管 CODEARTS REPO-分支管理:在控制台中管理分支

下一篇：代码托管 CODEARTS REPO-分支管理:在控制台中管理分支

代码托管 CODEARTS REPO-分支管理:基于Git分支的经典工作模式

意见反馈

0/200

提交成功！非常感谢您的反馈，我们会继续努力做到更好反馈提交失败！请稍后重试！

推荐文章

解决方案
相关专题