Git – 分支模型

Git 流程是开发人员在使用 Git 时可以遵循的一套准则。我们不能说这些准则是规则。这些不是规则；它是一个理想项目的标准。这样，开发者就会很容易理解这些东西。

它被开发者称为 “分支模型”，作为一个项目的中心库。开发人员工作并将他们的工作推送到主资源库的不同分支。

在一个项目中，有不同类型的分支。根据标准的分支策略和发布管理，可以有以下类型的分支。

• Master 分支
• Develop 分支
• Hotfixes 分支
• Release 分支
• Feature 分支

每个分支都有其意义和标准。让我们了解每个分支及其用途。

Git 主要分支

分支模型中的两个分支被认为是项目的主要分支。这些分支如下。

• master
• develop

主分支

主分支是项目的主分支，包含所有最终修改的历史。每个开发人员都必须使用主分支。主分支包含HEAD的源代码，总是反映项目的最终版本。

你的本地版本库有它的主干分支，总是与远程版本库的主干分支保持同步。

建议不要乱动主干。如果你编辑了一个小组项目的主干分支，你的改动会影响到其他人，而且很快就会出现合并冲突。

开发分支

它与主分支平行。它也被认为是项目的主分支。该分支包含了为下一个版本所做的最新开发修改。它拥有该版本的最终源代码。它也被称为 “集成分支”。

当开发分支达到稳定状态并准备发布时，应与主干分支合并，并标记为发布版本。

支持性分支

开发模式需要各种支持性的分支来进行并行开发，跟踪功能，协助快速修复和发布，以及其他问题。这些分支的寿命是有限的，使用后会被删除。

我们可能使用的不同类型的支持性分支如下。

• Feature分支
• Release分支
• Hotfixes分支

这些分支中的每一个都是为了一个特定的目的，并有一些合并的目标。从技术角度看，这些分支都很重要。

Feature分支

Feature分支可以被看作是主题分支。它用于为项目的下一个版本开发新的特性。这个分支的存在是有限的；当它的特性与开发分支合并后，它就会被删除。

要了解如何创建一个特征分支，请访问这里。

Release 分支

发布分支的创建是为了支持新版本的发布。高级开发人员将创建一个发布分支。发布分支将包含预先确定的功能分支的数量。发布分支应被部署到暂存服务器上进行测试。

开发人员可以在这个分支上进行小的错误修复和准备发布的元数据。所有这些工作完成后，就可以与开发分支合并了。

当所有的目标功能创建完毕后，就可以与开发分支合并了。发布分支的一些通常标准如下。

• 一般来说，高级开发人员会创建一个发布分支。
• 发布分支将包含预定数量的特性分支。
• 发布分支应该被部署到暂存服务器上进行测试。
• 任何需要改进的错误都必须在发布分支解决。
• 发布分支必须和主分支一样被合并回开发中。
• 合并后，发布分支与开发分支必须贴上版本号。

要创建一个发布分支，请访问 Git 分支。

要在合并发布分支后对分支进行标记，请访问Git标签。

Hotfix 分支

Hotfix分支与Release分支类似，都是为新的生产版本创建的。

hotfix分支的产生是由于对项目的立即行动。如果在生产版本中出现了关键性的错误，在项目中可能会有一个hotfix分支。修复错误后，这个分支可以与带有标签的主分支合并。