英文:

How to prevent devs from merging master into a Release branch?

问题

我们的团队采用了一个发布分支策略。在每次发布前的一周，我们会从主分支创建一个分支，例如“Release_1.2.3”。我们将此分支发送给质量工程师进行验证，并在发布前一周合并关键错误修复，然后将软件发布给用户。在此期间，功能开发在主分支上继续进行。一旦1.2.3版本正式发布，我们将Release_1.2.3合并回主分支。

这种方法通常对我们有效，除了一个缺点：在处理针对Release_1.2.3的更改时，一些开发人员错误地将主分支合并到他们的开发分支，然后手动删除不必要的更改。这会在将Release_1.2.3合并回主分支时造成问题，因为git会将所做的删除视为历史的一部分，并尝试在主分支上进行相同的删除操作。

我们尝试过向开发人员解释这个问题，但我们有一个庞大的团队为代码库做贡献（包括许多没有太多git经验的开发人员）。因此，我正在寻找一种自动化方法来阻止这类有害的合并。我们使用Github的分支保护规则来防止直接提交到主分支；我们能否在这里使用类似的方法？

另外，是否有一种程序化的方法可以检测一个分支是否包含有害的合并？我们可能可以将其整合到我们现有的CI系统中。

英文:

Our team uses a release branching strategy. A week before each release, we will create a branch off of master, e.g. "Release_1.2.3". We send this branch to our quality engineers for verification, and use the week prior to the release to merge in critical bug fixes before releasing our software to our users. During this time, feature development continues on master. Once Release 1.2.3 is officially released, we merge Release_1.2.3 back into master.

This approach generally works for us, except for one flaw: When working on changes targeting Release_1.2.3, some devs have incorrectly merged master into their development branch and then manually deleted the unnecessary changes. This causes issues when merging Release_1.2.3 back into master, since git views the deletions made as being a part of the history, and will try to make the same deletions on master.

We've tried to educate devs about this issue, but we have a large team contributing to the codebase (including many devs without much experience in git). Instead, I'm looking for an automated way to prevent these sorts of harmful merges. We use Github's Branch Protection Rules to prevent direct commits to master; can we use a similar approach here?

Alternatively, is there a programmatic way of detecting that a branch contains a harmful merge? We could potentially incorporate that into our existing CI system.

答案1

得分: 2

如果你能说服你的开发者在他们的`repo/.git/hooks`文件夹中安装一个客户端钩子，以便尽可能地控制该操作。

从[Git 2.24+（2019年第四季度）][1]开始，你可以使用类似于以下脚本的`pre-merge-commit`：

``` bash
#!/bin/sh

# 获取被合并分支的头部提交哈希
MERGE_HEAD=$(cat .git/MERGE_HEAD)

# 使用提交哈希获取分支名称
merge_from=$(git branch --contains $MERGE_HEAD | grep -v '^\*' | sed 's/^ *//')

if [ "$merge_from" != "master" ]
then
  exit 0
fi

echo "你不能将主分支合并到当前分支。"

exit 1

或者，如果在调用pre-merge-commit时.git/MERGE_HEAD不再存在，一个可能的选择是使用reflog：

#!/bin/sh

# 获取前一个HEAD的提交哈希
PREVIOUS_HEAD=$(git reflog -1 --pretty=%H HEAD@{1})

# 使用提交哈希获取分支名称
merge_from=$(git branch --contains $PREVIOUS_HEAD | grep -v '^\*' | sed 's/^ *//')

if [ "$merge_from" != "master" ]
then
  exit 0
fi

echo "你不能将主分支合并到当前分支。"

exit 1

这比服务器端钩子不够可靠，但也有一定帮助。

<details>
<summary>英文:</summary>

If you can convince your developer to install a client-side hook in their `repo/.git/hooks` folder, that allows for a control as close as possible of the action.

With [Git 2.24+ (Q4 2019)][1], you can use a `pre-merge-commit` similar to this script: 

``` bash
#!/bin/sh

# Get the commit hash of the head of the branch being merged
MERGE_HEAD=$(cat .git/MERGE_HEAD)

# Retrieve the branch name using the commit hash
merge_from=$(git branch --contains $MERGE_HEAD | grep -v &#39;^\*&#39; | sed &#39;s/^ *//&#39;)

if [ &quot;$merge_from&quot; != &quot;master&quot; ]
then
  exit 0
fi

echo &quot;You cannot merge master branch into the current branch.&quot;

exit 1

Or, if .git/MERGE_HEAD is no longer there when the pre-merge-commit is invoked, a possible option would be to use the reflog:

#!/bin/sh

# Get the commit hash of the previous HEAD
PREVIOUS_HEAD=$(git reflog -1 --pretty=%H HEAD@{1})

# Retrieve the branch name using the commit hash
merge_from=$(git branch --contains $PREVIOUS_HEAD | grep -v '^\*' | sed 's/^ *//')

if [ "$merge_from" != "master" ]
then
  exit 0
fi

echo "You cannot merge master branch into the current branch."

exit 1

That is less reliable than a server-side hook, but it can help.