下载文档原格式
git分支管理策略
Git分支管理策略是指在使用Git进行版本控制时，如何合理地管理分支，以便于团队协作和代码管理。
下面是一些常用的Git分支管理策略：
1. 主干开发策略
主干开发策略是指所有开发人员都在主干分支上进行开发，并且每个提交都会直接合并到主干上。
这种策略适用于小型团队或者项目规模较小的情况，可以保证代码的整体性和稳定性。
2. 长期分支策略
长期分支策略是指为每个版本创建一个长期维护的分支，所有相关的修改都在该分支上进行。
这种策略适用于大型项目或者需要长期维护的项目，可以保证不同版本之间的代码独立性和稳定性。
3. 功能分支策略
功能分支策略是指为每个新功能创建一个独立的分支，在该分支上进行开发和测试，并最终将其合并到主干上。
这种策略适用于需要同时
进行多个功能开发的情况，可以保证不同功能之间的独立性和稳定性。
4. 发布分支策略
发布分支策略是指为每个发布版本创建一个独立的分支，所有相关的
修改都在该分支上进行。
这种策略适用于需要频繁发布版本的情况，
可以保证不同版本之间的代码独立性和稳定性。
总之，选择合适的Git分支管理策略可以提高团队协作效率和代码管
理质量。
在实际应用中，需要根据项目规模、开发需求和团队特点等
因素进行选择和调整。
gitlab工程化分支结构在开发软件项目的过程中，一个好的分支管理结构是非常重要的。
GitLab是一个强大的版本控制系统，在实施工程化分支结构时可以提供极大的帮助。
下面将介绍如何在GitLab中建立工程化的分支结构。
首先，建议使用GitLab Flow分支模型来组织分支结构。
GitLab Flow是一种基于Git分布式版本控制系统的工作流程模型，它能够提供清晰的分支结构和规范的合并策略。
根据GitLab Flow，我们需要为不同类型的任务创建不同的分支。
通常，我们会有以下几种类型的分支：1. 主分支（main branch）：主分支是主要用于生产环境的分支，也被称为“生产分支”或“稳定分支”。
该分支应该是最稳定和可靠的版本，并且应该只包含已经经过测试和验证的代码。
2. 开发分支（develop branch）：开发分支是用于日常开发的分支。
所有的新特性开发和bug修复都应该在该分支上进行。
通常，该分支会包含来自不同开发者的多个特性分支。
3. 特性分支（feature branch）：特性分支是用于开发单独的功能或特性的分支。
每个开发者在开发新功能时应该创建一个自己的特性分支，并在完成开发后将其合并到开发分支上。
4. 修复分支（fix branch）：修复分支是用于解决bug的分支。
当发现bug时，应该创建一个修复分支用于修复bug，并在修复完成后将其合并到开发分支和主分支上。
此外，为了更好地组织和管理代码，还可以考虑以下几种分支用途：5. 预发分支（staging branch）：预发分支用于进行预发布测试。
当开发分支中的功能开发完成后，将代码合并到预发分支，并进行功能和性能测试。
6. 版本分支（release branch）：版本分支用于准备发布新的版本。
当准备发布新的版本时，从开发分支上创建一个版本分支，在该分支上进行最后的测试和准备工作。
最后，在GitLab中建立这样的工程化分支结构需要一些命名规范和合并策略。
gitlab项目创建分支流程
GitLab项目创建分支的流程如下：
1. 打开一个项目的页面，在页面的右上角，点击“Fork”按钮。
2. 输入你项目的名称，点击“Create Project”。
3. 进入项目页面后，点击左侧的“Branches”。
4. 在右侧的输入框中输入分支名称，然后点击“Create Branch”。
5. 创建完成后，可以在左侧的“Branches”列表中看到新创建的分支。
6. 点击该分支的名称，即可进入该分支进行代码编辑和提交。
7. 提交代码时，选择“Compose a commit”或者“Commit changes”，然后填写相应的提交信息即可。
8. 如果需要将该分支合并到主分支，可以进入主分支的页面，点击“Merge Branches”按钮，选择需要合并的分支，然后点击“Merge”。
9. 合并完成后，可以在主分支的页面中看到合并后的代码。
以上是GitLab项目创建分支的基本流程，具体操作可能会根据GitLab版本和操作系统的不同而有所差异。
如有需要，建议参考GitLab的官方文档或
咨询相关专业人士。
主干开发深入解析在软件开发的早期，程序员没有现代的版本控制系统。
相反，他们只能同时开发两个版本的软件，作为跟踪变更并在必要时回退它们的手段。
随着时间的推移，这显然是劳动密集型的、成本高昂且效率低下的。
随着版本控制系统的成熟，出现了各种开发风格，使程序员能够更轻松地发现错误，与同事并行编码，并加快发布节奏。
今天，大多数程序员利用两种开发模型中的一种来交付高质量的软件：Gitflow 和主干开发。
最先流行的Gitflow是一种更严格的开发模型，只有某些人可以批准对主要代码的更改。
这可以保持代码质量并最大限度地减少错误数量。
主干开发是一种更加开放的模型，因为所有开发人员都可以访问主要代码。
这使团队能够快速迭代并实施CI/CD。
什么是主干开发？主干开发是一种版本控制管理实践，其中开发人员将小的、频繁的更新合并到核心“主干”或”主分支“。
这是DevOps团队的常见做法，也是DevOps生命周期的一部分，因为它简化了合并和集成阶段。
事实上，主干开发是CI/CD的必须实践。
与其它具有长生命周期的功能分支策略相比，开发人员只会通过少量提交来创建短期分支。
随着代码仓复杂性和团队规模的增长，主干开发有助于保持生产版本的流畅。
Gitflowvs.主干开发Gitflow是另一种Git分支模型，它使用长期存在的功能分支和多个主分支。
与主干开发相比，Gitflow拥有更多、更长生命周期的分支和更大的提交。
在这个模型下，开发者创建一个功能分支，并直到功能开发完成才合并到主干分支。
这些长期存在的功能分支需要更多的协作才能合并，因为它们与主干分支差异更大，引入冲突代码的风险更高。
Gitflow还具有各种分支用于开发、修复缺陷、新功能和发布等。
合并这些分支之间的提交有不同的策略。
由于有更多的分支需要处理和管理，因此通常会有更多的复杂性，需要额外的计划会议和团队的审查。
主干开发要简化得多，因为它专注于作为修复和发布的主分支。
在主干开发中，假设主分支总是稳定的，没有问题，并且可以立即部署。
Git图形化⼯具介绍随git分发的默认的图形化⼯具git gui和版本分⽀图形化⼯具gitk。
⼀、GIT GUI主界⾯：各个按钮的意思基本与界⾯⽂字⼀致，与git的命令也差别不⼤。
在了解⾃⼰所做的操作情况下，各个功能点开看下就知道是怎么操作了。
即使不了解，只要不做push操作，所有的操作都在本地，基本也没什么影响。
⼤不了重新下载整个库好了，git下载库的时间确实⽐svn快很多，这也是git优势之⼀。
1.菜单栏：2.⼯作区变更、⽂件差异对⽐：点击⼯作区变更的⽂件，右侧窗⼝会显⽰⽂件差异对⽐。
吐槽下，对⽐的时候显⽰的差异以上下的格式显⽰，差异对⽐的体验⾮常不友好。
3.索引区：使⽤命令git add或点击”stage changed”按钮后，⼯作区变更会添加到该区域。
4.基本操作按钮：stage changed：将⼯作区的所有变更提交到添加到索引区；（其他在菜单栏中都有对应项，介绍菜单栏时⼀并介绍）mit信息输⼊框：⽤于commit时输⼊变更信息，与svn提交时填写的信息⼀样，主要⽅便后续查找或了解该次提交的⽬的。
mit⽅式：创建⼀次新的提交或者修改上⼀次提交。
对应于菜单栏中commit项中，new commit和amend last commit相同。
⼆、GIT GUI菜单栏：repository：git库相关操作，基本意思就是字⾯意思。
1）资源管理器中浏览该Git库⼯作空间⽂件，省去查找路径不断点击⿏标的操作。
2）启动Git bash⼯具（命令⾏⼯具）。
3）查看当前分⽀⽂件状态，不包括未提交的信息。
4）查看某个分⽀的⽂件（弹出框中可选择需要查看的版本、分⽀或标签），跟上⼀条差不多，⽤的⽐较少，可能是没有这⽅⾯的额需求。
5）可视化当前分⽀历史、可视化所有分⽀历史：弹出分⽀操作历史，也就是gitk⼯具，放到gitk⼯具中介绍。
edit：⽤于操作commit时操作信息输⼊，只能操作⽂字输⼊部分，你没有看错。
gitlab工程化分支结构在GitLab中，一个好的工程化分支结构能够提高团队的协作效率、代码的可维护性和品质。
以下是一些参考内容来帮助你建立一个有效的工程化分支结构。
1. Master分支（主分支）:- Master分支是项目的主要分支，应该始终处于可发布状态。
- 只有验证了的代码和测试通过的代码才能合并到Master分支中。
- Master分支应该用于发布的正式版本，每次合并到Master分支都应该与一个版本标签相关联。
2. Develop分支（开发分支）:- Develop分支是用于日常开发的分支，从Master分支派生出来。
- 所有的新功能开发和bug修复都应该在Develop分支上进行。
- 可以在Develop分支上进行集成测试来确保代码的功能正确性。
3. Feature分支（功能分支）:- 每个新特性或新功能都应该在一个独立的Feature分支上进行开发。
- Feature分支应该从Develop分支派生，并在开发完成后合并回Develop分支。
- 为了方便团队协作，可以使用命名约定来标识Feature分支，例如"feature/<feature_name>"。
4. Release分支（发布分支）:- Release分支用于发布新的正式版本。
- 在Develop分支上完成所有的功能开发和测试后，从Develop分支派生出一个Release分支。
- Release分支上可以进行最后的测试和修复bug。
- 当Release分支准备好发布时，将其合并回Master分支，并且与版本标签相关联。
5. Hotfix分支（修复分支）:- Hotfix分支用于修复Master分支上的紧急bug。
- Hotfix分支应该从Master分支派生，并且在修复完成后合并回Master分支。
- 为了方便团队协作，可以使用命名约定来标识Hotfix分支，例如"hotfix/<bug_number>"。
在Gitee中，分支是代码版本控制的重要组成部分，它允许开发者在不影响主分支的情况下进行并行开发和测试。
以下是关于Gitee分支的详细解释：1.分支的概念：在Git版本控制系统中，分支本质上是指向提交对象的可变指针。
默认情况下，会有一个名为master的分支。
当提交时，master分支会指向最新的提交。
其他分支可以基于master或其他分支创建，并在其上进行独立的开发和修改。
2.分支的创建：在Gitee中，可以通过Web界面或Git命令行工具创建分支。
例如，使用命令git branch <branch_name>可以在本地创建一个新分支，而git push origin<branch_name>可以将本地分支推送到Gitee远程仓库。
3.分支的切换：要切换到其他分支进行开发，可以使用git checkout <branch_name>命令。
切换分支时，HEAD指针会移动到该分支的最新提交上，工作目录也会更新为该提交的状态。
4.分支的合并：当某个分支上的开发完成后，可以将其合并到其他分支。
例如，将功能分支合并到主分支（通常是master或main分支）是一种常见的做法。
合并可以通过git merge <branch_name>命令完成。
如果存在冲突，需要手动解决冲突后再提交合并结果。
5.分支的删除：不再需要的分支可以被删除，以释放存储空间和保持版本控制的清晰。
在本地删除分支可以使用git branch -d <branch_name>命令，而要删除Gitee远程仓库的分支，则需要使用git push origin :<branch_name>命令（注意冒号前面的空格）。
在团队协作中，分支策略非常重要。
常见的分支策略包括：•主分支（master/main）：这是项目的主线，通常用于发布稳定版本。
只有经过测试和审核的代码才会被合并到主分支。
gitlab工程化分支结构【原创版】目录1.GitLab 工程化分支结构的概述2.GitLab 新建分支的操作方法3.GitLab 合并分支的操作方法4.GitLab 的版本管理策略5.GitLab 的线上 bug 修复操作演示6.GitLab 项目的其他分支管理策略正文一、GitLab 工程化分支结构的概述GitLab 是一种基于 Git 的开源代码托管平台，它提供了一系列强大的代码管理功能。
在 GitLab 中，工程化分支结构是一种常用的项目管理方式，它可以帮助开发者更好地组织和管理代码。
这种分支结构通常包括以下几个分支：- Master：主分支，用于存储经过测试和审查的稳定代码。
- Master-dev：开发分支，用于存储正在开发中的新功能和修复 bug 的代码。
- Feature：功能分支，用于开发新功能，通常是从 Master-dev 分支创建的。
- Release：发布分支，用于准备新版本的发布，通常是从 Master 分支创建的。
- Hotfix：热修复分支，用于紧急修复线上 bug，通常是从 Master 分支创建的。
二、GitLab 新建分支的操作方法在 GitLab 中，新建分支非常简单。
首先，打开你想要创建新分支的项目页面，然后点击“Branch”按钮。
在弹出的对话框中，输入你想要创建的新分支的名称，并选择一个父分支。
如果你想从现有的分支创建一个新分支，可以直接点击“Create branch”按钮。
如果你想从远程仓库创建一个新分支，可以先点击“Fetch”按钮，然后选择你想要创建新分支的远程仓库分支，最后点击“Create branch”按钮。
三、GitLab 合并分支的操作方法在 GitLab 中，合并分支也很简单。
首先，打开你想要合并的树枝页，然后点击“Merge”按钮。
在弹出的对话框中，输入你想要合并的另一个分支的名称，并选择一个合并策略。
如果你想保留合并后的分支，可以勾选“Keep new branch”选项。
本地分支解析git 通过可变指针来实现对提交数据的历史版本的控制，每当我们提交新的更新，当前分支(设为master)则指向最后一个提交更新A，而最后一个提交对象则存在一个指针指向前一次的提交更新Q。
如果我们创建一个新的分支，child，它和master共同指向A，这时，如果我们向child分支提交更新B，我们会发现child 指向B，而master依然指向A。
无论我们在child分支进行了任何开发，只要回到master分支，就能恢复到更新A的数据状态了。
在图片里，我们还注意到有一个head指针，一般来说，它会指向我们目前所在的工作分支。
现在它指向了我们的master分支，意思是master是我们目前的工作分支。
一旦提交更新，就会在master分支上提交。
现在，让我们看看与git 分支有关的操作命令：1. git branch [option] [name]如果不使用任何参数，它可以用来查看所有的分支,而在分支名前有*标记的则为主分支，如果加上name为创建新分支，,如git branch child,则会创建一个名为child 的分支，此外，它有一些常用的参数：2. git checkout [name]切换到对应的分支，对于上图，如果我们是使用git checkout child，我们的head 指针就会指向child分支了。
这时候，如果我们提交新的更新D，我们会发现：我们的D指向C，而C依然指向A，也就是说，以后我们在child分支上做的任何更新，都不会对master分支所在的之路造成任何影响！一旦使用了checkout命令，我们还会发现，不仅head指针会指向新的分支，而且当前工作目录中的文件也会换成了新分支对应的文件了。
此外，我们还可以使用git checkout -b [name]命令，它会新建一个分支，并自动将当前的工作目录切换到该分支上。
3. git merge [name]合并分支，有的时候，我们创建次要分支，可能是为了修改原有程序的bug，或为了拓展新的功能，这时候如果我们想把次要分支的修改何并进主分支中，我们可以使用git merge命令来实现。
一个成功的Git分支模型本文中我会展示一种开发模型，一年前该模型就已经被我用在所有的项目中（包括工作中的项目和私有项目），结果是非常成功的。
我早就想为此写点东西，可直到现在才有时间。
本文不会讲述任何项目的细节，只会涉及到分支策略和发布管理。
本文使用Git作为所有源码的版本控制工具。
为什么是Git？要全面了解Git与其它集中式版本控制系统相比的优劣，可以参考这个页面。
这方面的争论可谓是硝烟弥漫。
作为一个开发者，所有这些工具中我最钟情于Git。
Git的的确确改变了人们考虑合并及分支的方式。
在我之前所处的经典CVS/Subversion世界中，合并/分支总是被认为是有点可怕的事情（“小心合并冲突，丫会恶心到你”），因此你只应偶尔干这种事情。
但有了Git，这类事情就变得非常简单，分支及合并甚至被认为是你日常版本控制操作的核心之一。
例如，在CVS/Subversion的书中，分支及合并往往在后面的章节才被介绍（针对高级用户），但在每一本Git的书中，该内容已经在前3章中介绍（基础）。
简单及易重复性带来的好处就是，分支及合并变得不再可怕。
版本控制工具本该帮助我们方便的进行和分支及合并操作。
简单介绍下工具后，让我们来看开发模型。
我讲介绍的模型本质上只是一组步骤，每个团队成员都必须遵循这些步骤以形成一个可靠管理的软件开发过程。
去中心化但仍保持中心化在这个分支模型中我们使用的，且被证实工作得很好的仓库配置，其核心是一个中心―真理‖仓库。
注意只有该仓库才被认为是中心库（由于Git是DVCS [分布式版本控制系统]，在技术层面没有中心库这一东西）。
之后我们用origin指代该仓库，因为大多数Git用户都熟悉这个名称。
每个开发者都对origin做push和pull操作。
不过除了这种中心化的push-pull关系外，每个开发者还可以从其他开发者或者小组处pull变更。
例如，可能两个或更多的开发者一起开发一个大的特性，在往origin永久性的push工作代码之前，他们之间可以执行一些去中心化的操作。
英文：/posts/a‐successful‐git‐branching‐model/参考译文：/translate/2010/10/30/a‐successful‐git‐branch.html这篇文章我想介绍一下一年前就提到过的我所有项目(工作/私有)都在使用的开发模式，经过事实验证，确实非常可行。
很早就想写了，一直没腾出时间。
我不会涉及项目的细节，只是谈谈分支的使用策略和发布管理。
上图是使用Git这个版本控制工具来管理所有源码的。
为什么使用Git如果要看详细的Git与集中式源码管理工具的优势与劣势，可以参见这篇文章，那里有很多口水仗。
作为一个开发人员，所有的源码管理工具中，我最喜欢Git。
Git从根本上改变了开发人员对分支和合并的使用，传统的CVS/SVN，分支和合并都是高级话题，而且使用起来稍显麻烦，隔一段时间才会用一次。
但是有了Git，这些操作就成了家常便饭。
由于使用简单，方便重复操作，分支和合并不再是让人望而生畏的操作，版本管理工具应该尽可能地对分支/合并提供最好的支持。
工具谈得差不多了，回到开发上。
如果想管理好软件的开发流程的话，我待会要讲到的模型其实是一些每个开发人员都应该遵守的步骤。
分布式但集中化我们要使用的仓库是一个"中心库"，当然这个中心库只是被认为是这样(因为Git是分布式的，从技术层面上来说是没有中心库的)，我们将把这个仓库叫做"origin"，因为Git用户都熟悉这个名字。
每个开发者都可以pull和push到origin，但除了中心化的push-pull关系外，每个开发者还可以从其他开发者那pull changes，来构成小团队。
比如说，当开发一个比较大的新特性时，在把正在进行的工作过早地提交到origin之前，安排2个或多个开发者一起协作可能会很有用。
上图中有几个小团队：Alice和Bob，Alice和David，Clair和David。
从技术角度来说，其实就是Alice定义了一个叫Bob的Git remote，指向到Bob的仓库，反之亦然。
主(main)分支中心仓库有两个分支：At the core, the development model is greatly inspired by existing models out there. 中心仓库有两个无限期存在的主分支：* master* developorigin上的master分支，Git用户应该很熟悉了，跟master并行的有一个叫作develop的分支。
我们把origin/master作为HEAD源码总是表示production-ready(可随时部署)状态的主要分支。
我们把origin/develop作为HEAD源码总是表示下一个发布的最新发展变化状态的主要分支。
有时候也叫它为“合并分支”，每日构建也是基于此分支。
当develop分支上的源代码达到了一个稳定状态并准备发布时，所有的改变都要合并到master分支，并标上版本号。
如何实现的下面细说。
因此，每次改变合并回master时，都会有新的部署发布。
我们对这点非常严格要求，因此从理论上讲，这点可以自动化实现。
每次master上有提交时，就可以使用Git hook脚本来构建并发布软件到生产服务器上去。
支持(supporting)分支我们的开发模型使用了一些支持分支放在master和develop分支的旁边，用来辅助开发小组之间的并行开发，解除特性追踪，准备生产发布和解决生产现场出现的问题。
不像主(main)分支，这些分支是有时间限制的，因为他们最终都会被移除。
我们将使用到的不同分支：* Feature branches* Release branches* Hotfix branches每个分支都有特定的作用并严格规定了它们源自那个分支和将来合并到哪个分支去。
这些后面再说。
划分这些分支绝不是从技术层面来的，而是从它们的功能上划分的。
它们是十足的旧的git分支。
Feature 分支* 继承分支: develop* 合并分支：develop* 命名规范：除了master,develop,release-*,hotfix-*Feature branches是用来为短期或长期的发布开发新特性。
当开始开发新特性时，很可能不知道这个特性会出现在哪个目标版本。
一旦开发完成就可以合并到develop，当然如果开发失败，就可以抛弃。
Feature分支一般只存在于develop仓库，不再origin中。
创建一个特性分支当开发一个新特性时，从develop分支上进行分支$ git checkout -b myfeature developSwitched to a new branch "myfeature"将完成的特性合并到develop中$ git checkout developSwitched to branch 'develop'$ git merge --no-ff myfeatureUpdating ea1b82a..05e9557(Summary of changes)$ git branch -d myfeatureDeleted branch myfeature (was 05e9557).$ git push origin develop--no-ff(no fast foward)参数，使得每一次的合并都创建一个新的commit 记录。
即使合并是fast-foward，这样可以避免丢失feature分支的历史存在，和各小组提交特性的信息。
比较下面的两个图：在右边的情况下，除非手动的阅读所有的日志信息，你不知道是哪个提交对象应用的新特性。
回到整个特性(例如一个组的提交)，后一种情况实在让人头疼，所以使用--no-ff参数很容易解决。
可能第一种情况会多创建一些(空的)提交对象，但是收益远大于消费。
不幸的是，我还没有发现一种方法可以让git merge默认带有--no-ff参数，但真的是应该有。
Release 分支* 继承分支: develop* 合并分支：develop 和 master* 命名规范：release-*Release branchs是为新的production release作准备的。
他们可用来做最后的细节问题(dotting of i's and crossing t's)的考虑，甚至允许小的Bug修复和准备发布的元数据(版本号，构建日期等)。
在一个发布分支上做完所有的这些工作之后，develop分支被清除来接受下一个大的发布的新特性。
从develop分支合并到release分支的关键点是:develop分支达到了release分支所要求的状态。
至少所有针对该release的特性要被合并到develop分支中。
至于那些将来会有的特性可以先放一放。
然后就是为接下来即将要发布的版本分配一个版本号。
创建发布分支Release branches是源自develop分支而创建。
举个例子，假如1.1.5是当前的production release，然后即将发布一个大的版本发布。
develop的状态已经可以发布下一个版本了，经过商榷后，决定它为1.2版本(而不是1.1.6或2.0)。
所以我们创建一个release分支，并以新的版本号来命名它。
$ git checkout -b release-1.2 developSwitched to a new branch "release-1.2"$ ./bump-version.sh 1.2Files modified successfully, version bumped to 1.2.$ git commit -a -m "Bumped version number to 1.2"[release-1.274d9424]Bumped version number to 1.21 files changed,1 insertions(+),1 deletions(-)这个新分支可能会存在一定的时间，直到release被明确的发布。
这段时间内，bug修补可以在这个分支上进行(而不是develop分支)。
添加新特性(尤其比较大的)是不允许的。
他们最后还是要被合并到develop，然后继续在develop分支上开发，直到下一个版本。
完成一个release分支当release branch已经准备就绪并即将发布，还需要做几件事。
首先，release分支将被合并到master 分支上(切记，每一个提交到master上的提交都是一个新版本)。
然后，master上的commit都要添加tag，方便将来查看和回滚。
最后，release上所做的修改必须合并到develop分支上，以保证将来的发布版的bug已被修补。
前两个步骤是：$ git checkout masterSwitched to branch 'master'$ git merge --no-ff release-1.2Merge made by recursive.(Summary of changes)$ git tag -a 1.2发布版已经做好了，为它打上标签以供将来参考。
注：你可能会想用-s或-u <key>参数来秘密的打上你的标签。
为了把release上的改变保存到develop，我们需要将它合并回develop中，所以：$ git checkout developSwitched to branch 'develop'$ git merge --no-ff release-1.2Merge made by recursive.(Summary of changes)这个步骤可能会导致冲突(因为我们已经改变了版本号)，如果这样的话，解决冲突，然后再提交。
现在一切都完成了，我们不再需要它了，可以把release branch干掉了。
$ git branch -d release-1.2Deleted branch release-1.2 (was ff452fe).Hotfix分支* 继承分支: master* 合并分支：develop 和 master* 命名规范：hotfix-*Hotfix branch和Release branch有几分相似，都是为了新的production release而准备的。
比如运行过程中发现了bug，就必须快速解决，这时就可以创建一个Hotfix branch，解决完后合并到master分支上。
