7

我已经阅读了多种不同的 git 分支策略，我很惊讶 master 分支经常被用作“生产就绪”分支，并且会有一个额外的 uat 和 dev 分支。我正在考虑使用相同的 3 个分支设置我们的 git 存储库，但让“master”包含开发代码并添加生产和 uat 分支。这样，开发人员可以简单地合并到默认的 git 分支（即“master”）。有理由不这样做吗？

克，

科恩

4

4 回答 4

9

没有特别的理由不选择一个工作流程而不是另一个工作流程，对于 Git，通常由开发团队自行决定他们的最佳实践。

您提到的生产就绪主方法通常有多个开发分支（有时称为功能分支），然后选择主作为放置所有这些的最终位置，因为通常应该只有一个主分支（通常只有一个生产版本）。

这是有多少公司在工作，但肯定不是全部。许多其他人使用“不稳定的主”方法，它遵循与您提到的类似的模式 - 有些人有一个生产存储库，他们自己的主和分支被认为是不稳定的，并且团队负责人在代码中推送到生产存储库特定的分支被认为是生产就绪的。

Git 的关键方面是每个人都有自己的本地存储库，有自己的分支和主库。这使他们可以随时为他们认为合适的任何邪恶目的创建自己的私有分支，但这确实使定义分支名称的目的更加难以执行。

于 2012-05-01T12:14:14.887 回答
6

使用 DVCS（分布式版本控制系统）理解的关键概念是，您没有一个工作流（分支之间的合并），而是两个：存储库之间的发布（推/拉）。
请参阅“哪些 git 分支模型实际上有效？ ”

这意味着您将克隆周围的存储库，并且对于每个克隆，您要问的是：

如果我“默认”克隆一个 repo（没有特殊参数），我想看什么内容？

在克隆的 repo 包含的所有可能的分支中，该内容将是您的“ master”分支。
您可以更改“默认分支”：请参阅“ Git：在裸存储库中更改活动分支的正确方法？ ”。

因此，如果您有一个专门用于开发的 repo，master 分支将代表“有效”的最新代码，其他分支将用于各种“实验”。
这基本上就是 Git 存储库本身遵循的内容：请参阅“ Git/Git 工作流程”。

但是任何其他克隆都可以专用于其他开发生命周期步骤（uat -- 用户验收测试，sit -- 系统集成测试， -- pre-prod 或 prod）。
在这种情况下，他们的 ' master' 分支将具有不同的含义，以适应该 repo 所扮演的角色。

于 2012-05-01T13:04:01.450 回答
2

我认为一个很好的起点是实际阅读Git 推荐的工作流文档。他们谈论使用 master 作为稳定和功能分支。

摘录：

毕业~~~~~~~~~~

随着给定功能从实验到稳定，它也在软件的相应分支之间“毕业”。 git.git使用以下“集成分支”：

  • 'maint' 跟踪应该进入下一个“维护版本”的提交，即最后发布的稳定版本的更新；

  • “master”跟踪应该进入下一个版本的提交；

  • 'next' 旨在作为主题的测试分支，用于测试 master 的稳定性。

还有第四个官方分支，用法略有不同：

  • 'pu'（提议的更新）是一个集成分支，用于尚未准备好包含的内容（请参阅下面的“集成分支”）。

四个分支中的每一个通常都是其上一个分支的直系后代。

从概念上讲，该功能进入一个不稳定的分支（通常是“next”或“pu”），一旦被认为足够稳定，就会“毕业”到“master”以用于下一个版本。

于 2016-04-14T13:41:06.980 回答
1

这一切都取决于开发人员的舒适度。您可以继续使用您解释的方法。此外，可以有多个分支用于基于 sprint 或任何其他方法进行提交。每次您要在生产中部署代码时，合并已推送提交的特定分支和方法。

于 2012-05-01T13:10:00.657 回答