我可以在git中强制执行仅合并分支吗?

时间:2010-11-03 02:13:48

标签: git merge workflow branch git-branch

我正在使用git,我正在设置以下分支来支持我的工作流程:

  • 发布,仅包含已发布的软件,
  • testing,包含发布给测试组的软件,
  • 发展,这是发展的地方,
  • some_topic_branch,其中添加了功能等。

主题分支从分支并合并到开发中。当我们准备好发布测试版时,测试会在开发中进行合并。当测试版本被批准用于生产时,在测试中发布合并。

这很容易设置,但我想知道git中的强制执行选项。例如,是否可以实施一个策略,其中发布分支上的唯一提交是从测试中合并,防止更改直接在发布分支上发生?

4 个答案:

答案 0 :(得分:11)

好吧,有点儿。但我不认为你想去那里。

正如Jason所说,有一些钩子可以用来阻止某些行为。在这种情况下,我们可以使用pre commit hook来阻止任何人运行“git commit”。但这在几个方面存在问题:

  1. 出于各种安全原因,git挂钩不随存储库一起分发,因此您无法强迫人们在其存储库中使用挂钩。请记住,他们的存储库是他们自己的,不是由你决定他们在他们的存储库中做了什么。
  2. 当您进行拉动或合并并发生冲突时会发生什么?为了解决这些冲突,你必须能够使用我们刚刚禁用的“git commit”。
  3. 这只会产生比解决的问题更多的问题。

    但是,您可以通过其他方式解决此问题。您可以创建一个强制执行这些原则的工作流程。例如,假设您有人A负责从测试分支到发布分支的合并。如果您只让这个人能够将更改推送到中央存储库(或者人员存储库是“中央”存储库),他/她可以从测试存储库的测试分支或测试分支中获取更改。测试员B(用你的想象力)。

    这里重要的是要意识到您可以通过设计彼此之间的变更沟通来实施策略。不是每个人都需要能够将他们的更改推送到一个存储库。哎呀,他们根本不需要推动他们的改变。测试人员/人员可以在他们想要测试的东西之后立即从开发人员那里获取更改,这样您就可以让测试决定他们何时准备好进行新的更改,而不是让开发人员决定测试人员应该何时获得他们的东西。同样的原则。

答案 1 :(得分:4)

您可能需要查看Git flow,了解有关此类workflow的更多想法。

答案 2 :(得分:2)

你应该可以通过使用一些git钩子来强制执行此操作。

答案 3 :(得分:0)

最近,用于授权实施的框架 gitolite 可以帮助实施各种策略,例如只允许测试人员合并到“{{ 1}}“分支。

此外,gitolite建议用VREFs(在“Gitolite Update Hook exclude a repository”中解释)定义许多“更新挂钩”的可能性,这些挂钩将控制提交到由gitolite管理的repo。

但是所有这些控件都是用于“中央”仓库,而不是用于所有克隆在各个开发人员工作站上的下游回购。