1

我们有一个中央 Git 存储库，开发人员可以从中获取和推送更改。他们在默认的主分支上进行更改。我们的持续集成 (CI) 工具从这个默认的主分支构建工件，并且是负责将我们想要测试的东西提升到“UAT”分支的实体（这实际上是由构建主管人员单击将进行促销的 CI 工具网页）。CI 工具还负责将代码从 UAT 提升到“生产”分支。UAT 和生产分支的目的是捕获提升到 UAT 和生产的内容。UAT 分支上没有开发，生产将仅包含不常见的“热修复”形式的“开发”，因为我们的开发/发布迭代非常快（1 周迭代）。

如果我们可以轻松做到这一点，我们希望设置一个控件，以防止有人错误地直接对 UAT 和生产分支进行开发更改。一种想法是在中央服务器上安装一个挂钩，以确保只有 CI 工具用户才能对 UAT 和生产进行更改。我们还认为我们可以有一个开发人员使用的中央仓库，它只包含主分支，并有一个包含 UAT 和生产分支的第二个仓库。CI 工具将与两个 repos 进行通信——它将查看 repo 的开发以查看何时有更改，并使用第二个 repo 将其推广到 UAT 和 Production 分支。

这是人们通常会做的事情吗（为了开发和推广目的而单独的回购？）它会比服务器挂钩方法更好吗？

4

2 回答 2

2

出于您订阅的目的，我会说通过钩子防止未经授权的提交和合并是要走的路。您不必特别注意要跟踪的遥控器。你也可以很容易地一直来回合并。

于 2012-08-05T18:28:36.120 回答
0

我想说克隆一个 git repo 既便宜又易于设置。如果 CI 用户/构建大师能够将某些东西推广到 UAT/生产，为什么不将更改推送到单独的存储库？可能类似于 linux 内核开发模型。每个更改都已由开发人员签入，由 CI 用户测试，然后授权并推送（可能已签名）到发布存储库。

即使可以将某些领域的提交限制为某些人，我不认为这是使用分布式工具的方式。我真的很喜欢开放存储库，并且可能将其他专门的存储库用于某些用途。Git 会保留所有内容，并且您不会通过推入其他存储库而丢失信息。所以作者始终是作者——只有提交者会改变。

这是一篇非常好的文章，其中包含大量信息： What git branching models 实际上起作用

于 2012-08-05T19:42:27.113 回答