防止错误的git合并

时间:2019-01-15 19:19:42

标签: git git-merge git-rebase git-flow git-config

现在,在工作中,我们为产品的不同版本提供了不同的git分支。例如:名为v1.0,v2.0,v3.0的分支和一个master分支。

不同的客户运行不同的版本,但是新功能仅合并到最新版本分支和master分支中。但是,错误修正仍合并在较低版本的分支中。假设在v1.0上发现了一个错误,那么我们当前的git工作流程是:

  1. 要从v1.0创建功能分支,
  2. 进行修复
  3. 合并回v1.0并推送
  4. 将v1.0合并到v2.0中并推送
  5. 将v2.0合并到v3.0中并推送
  6. 将v3.0合并到主服务器中并推送

这会导致在较低版本中发现的错误修正包含在该产品的所有更高版本中。

因此,

V3.0将包含v2.0包含的所有提交,以及在v3.0版本上进行的其他功能提交。 Master将包含v3.0包含的所有提交,以及产品的将来版本的其他功能提交等。

现在,我们已经有几次人们以错误的方式进行合并,而不是向上还是向下。因此,他们将v3.0合并为v2.0。从某种意义上讲,这会导致巨大的问题,即只要在该软件的v2.0上为客户提供该产品的新的错误修正版本,他们实际上就会获得v3.0。

以错误的方式进行这些合并实际上很容易,但是后果可能会很大,尤其是如果长时间未检测到错误的合并。

有什么方法可以防止人们在版本分支中向下合并,而只能向上合并? (因此从v1.0到v2.0等。)

我应该提到,我们无法在服务器端定义任何自定义git-hooks。

1 个答案:

答案 0 :(得分:1)

一种完全可靠的方法,您已经完全排除了:

  

我应该提到,我们无法在服务器端定义任何自定义git-hooks。

否则,您所拥有的都是不可靠的依赖于每个用户的方法。

每个用户都可以安装自己的钩子。您可以设置预推钩,以进行检查以确保您没有做自己不想要的事情。如果每个用户都这样做,并且前提是每个用户也没有绕过钩子,那么这将阻止执行您不喜欢的操作的推送。

编写钩子并非一帆风顺,当然,如果有人无法安装钩子,安装不正确或绕过钩子,则将无效。但是它可用。

(虽然没有合并前的钩子,但是没有合并前的钩子。这就是为什么我建议使用合并前的钩子。)