如何使用简单的分支策略来保护您的 Git 项目

良好的分支策略可以使项目源代码获得一致且安全的数据，所有协作者可以在更短的生命周期内共享和访问这些数据。

您必须以灵活的方式设计项目模型，以便对所有成员角色和权限进行良好的管理。

我要谈论的并没有什么令人惊讶的新鲜事。您可能已经知道一些 git 概念和命令，但我的想法是利用您的思维过程，从您已经了解的 Git 中做出更好的选择。

本文的要点：

您将了解什么 git 工作流程可能适合您当前的项目代码
根据项目开发的代码类型，在不同的并行运行分支上隔离和组织项目代码。
采用灵活的实时分支模型
了解如何使用gitlab  （一种云托管的版本控制服务）在分支上设置哪些准则。
使用受保护的分支和策略在 GitLab 上托管您的项目。
简要想法/大纲
根据您的项目模型，Git 既可以充当集中式版本控制系统，也可以充当分散式版本控制系统 (VCS)。正如我们所知，Git 的分布式特性是为了方便大量贡献者同步协作他们的工作而开发的。理想的 git 工作流程模型的选择取决于贡献者的数量、存储库和分支的权限级别层次结构，以及所选的架构模型是集中式还是分散式？

一个理想的分支策略，在实践中应该声明一套指导方针，保护分支免受读写权限，并限制对分支的未经授权的创建、删除、强制推送。

无论您是在Linux 服务器上还是在Web 托管、基于云的源代码控制服务上维护源代码，都可以以结构化方式创建分支并保护它们的某些成员和操作。

我从之前的实时航空公司计费项目中采用的分支模型创建起来非常简单并且易于遵循。管理团队、开发、测试、运营和 QA 团队等不同团队和谐地合作，为项目源代码做出贡献。

Git 分支模型

这种方法让您只有稳定的 QA 批准的提交才能通过压缩合并策略从“ release ”分支推送到“ prod ”分支。“ master_prod ”仅接受来自“ prod ”分支的源代码的最终提交。

主要代码开发发生在功能和主题分支上。

“master_prod”是部署就绪分支。CD 管道可以在此分支上实现自动化，以便在 DevOps 环境设置中进行持续部署。

所需先决知识
我假设你：

了解git 概念和命令，并了解如何使用 git 工作流程开发项目
了解git 分支 — 创建、合并、解决冲突和删除
了解如何将远程存储库添加或克隆到 GitHub 或 GitLab 上的本地项目以发布您的作品。
了解我们为什么、何时以及如何使用 git fetch、pull 和 push 来与远程存储库同步并与协作者协调工作。
一般的思考过程如下：

开发分支模型
决定 VCS 和模型架构的类型
选择 git 工作流程模型
选择分支策略
创建分支并定义准则
定义成员角色和权限
保护 gitlab 上的分支并维护分支指南
VCS 和模型架构类型
所需的版本控制架构取决于您的项目数据、管理设置以及团队规模。在具有许多协作者的大型项目中，必须有灵活的源代码管理 (SCM) 设置。

假设您已经赞成使用 Git，因为它快速、分布式、灵活，具有强大的分支和合并功能，并且保留良好的历史记录，可以让您修复错误并以有组织的方式分析代码; 分布式版本控制系统（DVCS）架构将是您的选择。

在 DVCS 模型中，所有机器既充当“节点”又充当“中心”。然而，在集中式版本控制系统中，每个开发人员仅充当“节点”，而中央服务器充当“集线器”。

如果您的团队有早期集中式 VCS（例如 Subversion、CVS 或 ClearCase）的背景，那么 Git 的集中式工作流程模型很可能会吸引您。

您希望在大型项目中使用 Git 作为 VCS 的另一个原因是维护数据完整性；因为 git 永远不会允许你们覆盖彼此的工作。

每次开发人员尝试将新提交推送到自上次签出以来已经接受其他开发人员提交的中央存储库时；您的推送将被拒绝，因为它不会是快进合并。您必须获取并合并其他人的更改，然后在此基础上进行工作。

这样，许多开发人员就可以通过无数分支和谐地工作，贡献每个人的工作，而无需干涉彼此的更改。

有了这个令人信服的说明，我们将继续为您的项目选择 Git 分布式版本控制系统 (DVCS)。阅读git 3 层架构工作流程可能会感兴趣，以快速介绍 git 工作流程并了解所使用的 git 术语。

选择 Git 工作流程模型
无论您遵循哪种git 工作流程模型，良好的分支策略都会让您更接近稳定的模型。Git 提供了强大、灵活、稳定的工作流程模型，可以轻松地在庞大的团队中进行协作工作。

具有共享存储库模型的Git集中式工作流程为您提供与 SubVersion、ClearCase 或 CVS 版本系统相同的舒适区，同时保持各个贡献者之间的数据完整性。

通过设置集成管理器工作流程，可以在具有多个远程存储库概念的大型项目中实现分布式方法。在这里，每个开发人员都必须对其自己的公共存储库进行写入访问，而对其他人的公共存储库进行只读访问。维护者扮演的主要角色是协作（拉取和合并）每个开发人员的工作到自己的存储库中，并将其发布到主存储库上，然后其他开发人员可以从中克隆。

如果您正在开发一个具有多个远程存储库的大型项目，请选择独裁者和中尉工作流程。工作的协作被分配给拥有存储库的特定部分的各个副官，并且仅合并来自某些开发人员的工作。独裁者被分配来拉取和合并所有副官的更改，最终将所有协作工作发布到主存储库。

----

注意：在选择工作流程模型或模型组合时，考虑将影响实时工作流程的真实场景变量也很重要。

贡献者数量 –> 如何使更改不断更新 - 在进行自己的更改之前首先采用拉动策略。
工作流程 –> 集中式还是分布式？合并前是否对代码进行了审查，是否有合并请求程序可供遵循？
提交访问权限 -> 应在哪个分支上分配哪些读写访问权限？
独裁者和中尉工作流程将是大型项目的理想选择。

选择分支策略
下一步是创建不同的分支并为每个分支分配角色。如果您需要快速了解什么是 git 分支以及如何创建和管理它们；请参阅Git — 模块 3：分支和合并

根据分支用于的代码开发类型，分支可以简单地分类为：

稳定/集成或长期运行的分支- 这些通常具有干净的历史记录，没有三向合并，并且具有较短的用户友好历史记录。在我们的项目示例中，“prod”和“master_prod”是两个这样的稳定​​分支。

发布分支将所有功能和修补程序分支的更改提交合并为一个。这是验证、审查和解决冲突的地方。（参考：git解决冲突-第6点。合并工具（diffmerge）：解决冲突）。

发布分支应该有一个非线性且混乱的提交历史记录，这样可以更容易地列出整个项目的提交历史记录，并分析项目是如何开发的、哪些提交是由谁创建的以及进行了哪些更改。

功能分支从主开发分支（更常见的是“主”分支）分支出来。这用于开发人员开发特定代码。这些是针对特定代码问题或修复的短期分支；例如反馈甚至新功能。功能分支上的工作在获得批准后将合并到稳定分支中。我的功能分支是“dev”和“uat”。

不稳定或修补分支是为开发和测试错误修复而创建的短期私有快速修复分支。它们被合并到功能分支中并被删除。“hotfix”在我的项目中是一个不稳定的分支。