我可以在git中强制执行仅合并分支吗？ [英] Can I enforce a merge-only branch in git?

问题描述

我使用git，并且设置了以下分支来支持我的工作流程： 发布的软件，包含发布到测试组的软件的

测试，

开发，这是开发过程的地方，

some_topic_branch，其中添加了功能等。

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

这很容易设置，但我想知道git中的强制选项。例如，是否有可能强制实施一个策略，即发布分支上的唯一提交是否与测试合并，从而防止直接在发布分支上发生更改？

解决方案

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

正如Jason所说，你可以使用钩子来防止某些行为。在这种情况下，我们可以使用pre commit hook来防止任何人运行git commit。但是这在很多方面都存在问题：

1. 由于各种安全原因，git钩子不会与存储库一起分发，所以你不能强迫人们在他们的仓库中使用你的钩子。请记住，他们的存储库是他们自己的，而不是由您决定他们在存储库中做些什么。 当您执行pull或merge并发生冲突时会发生什么？为了解决这些冲突，您必须能够使用我们刚才禁用的git commit。

问题比它解决的问题。

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

这里重要的是认识到你可以通过设计如何沟通彼此之间的变化来实施一项政策。不是每个人都需要将其更改推送到一个存储库。哎呀，他们甚至根本不需要推动他们的改变。测试人员/人员只要想要测试一些东西，就可以从开发人员处获得变更，这样，您就可以让测试决定何时准备好引入新变更，而不是让开发人员决定测试人员何时应该获得变更东东。相同的原则。

I'm using git, and I'm setting up the following branches to support my workflow:

• release, which only contains released software,
• testing, which contains software released to the testing group,
• develop, which is where development happens,
• some_topic_branch, where features, etc. get added.

Topic branches branch from and get merged into develop. When we're ready for a testing release, testing merges in develop. When a testing release is approved for production, release merges in testing.

This is all easy enough to set up, but I'm wondering about the enforcement options in git. For example, is it possible to enforce a policy where the only commits on the release branch are merges from testing, preventing changes from happening directly on the release branch?

解决方案

Well, sort of. But I don't think you want to go there.

As Jason say, there are hooks that you can use to prevent certain behavior. In this case we could use the pre commit hook to prevent anyone from running "git commit". But this is problematic in several ways:

1. For various security reasons, git hooks are not distributed with the repository, so you cant force people to use your hooks in their repositories. Remember, their repositories are their own, not for you to decide what they do in their repositories.
2. What happens when you do a pull or merge and get conflicts? In order to solve these conflicts you must be able to use "git commit", which we just now disabled.

This just creates more problems than it solves.

However, you could solve this in other ways. You could create a workflow that enforces these principles. For example, imagine that you have person A in charge of doing the merge from the test branch into the release branch. If you let only this person be able to push the changes to the central repository (or that persons repository IS the "central" repository), he/she could pull in changes from the test branch of the test repository, or the test branch of tester B (use your imagination).

What's important here is to realize that you can enforce a policy by designing how you communicate changes with each other. Not everyone need to be able to push their changes to one repository. Heck, they don't even need to push their changes at all. The test people/person could pull in changes from the developers, as soon as they want something tested, and this way you could let test decide when they are ready to pull in new changes, not let the developers decide when the testers should get their stuff. Same principle.

这篇关于我可以在git中强制执行仅合并分支吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！