Question

我们有一个非常标准的git工作流程，但我有一个烦恼：主服务器领先于开发，因为我们每次部署都会创建一个从开发者到主服务器的合并提交。

首先我们的工作流程：

master branch-始终干净并且可用于部署
development branch-收集新功能/错误修复（如果有的话）审核并批准
feature branch-仅具有一个新分支一项功能需要进行的更改（它是从development branch分支出来的）

每个成功的请求请求（功能>开发）都会创建一个合并提交，这很好。

但是，每个部署（开发>主服务器）也会创建一个 merge-commit （合并合并提交），它仅存在于主服务器中。因此，发生的情况是，在进行20次部署后，主分支要比开发分支提前20次提交。

您如何处理这种行为？您是否不时合并master> dev（实际上除了创建无用的merge-commit之外什么都不做）？

重新开发分支似乎不是一个选择，因为那样一来，每个开发人员都会失去跟踪的远程分支。

Answer 1

您要的内容称为“快进”合并。既然您提到了请求请求，我假设您正在使用某种方法来为您管理分支（GitHub，BitBucket等），因此完成所需操作的确切说明可能会有所不同。

给出此状态：

master o-o-o-o
              \
development    o-o-o

您的软件在合并时可能会应用--no-ff标志（这是标准行为，因为您希望在将功能部件合并到development中时进行合并提交）。在命令行中，这等效于：

git merge --no-ff development

master o-o-o-o-------o
              \     /
development    o-o-o

但是，如果要避免合并提交，您确实想快进分支：

git merge --ff development（--ff是不必要的，因为它是默认行为）

master/development o-o-o-o-o-o-o

注意：

如果执行此操作，则会失去查看development何时合并到master中的功能。这可能不是一个问题（或者您可能以其他方式（例如使用标签）解决了这个问题。）
如果您确实在master上进行了唯一的提交，而无法进行快速转发，则仍将创建合并提交。但是，如果无法进行快速转发（--ff-only中的唯一提交或已经是最新的），则可以使用标志master来出错。

Answer 2

我们就是这样做的：当您认为功能已经就绪（“代码删除”）时，从release分支development。在此处运行昂贵的测试并修复错误，然后将release合并到master，然后将master合并回到development。再次启动新的release分支。

您也可以在每次部署后将master合并回development，但是在release分支中没有任何实际更改，这没有多大意义。

Answer 3

我们有3个基本分支机构进行开发，准备和掌握。无论我们构建什么新功能，都将保存在功能/分支中并在开发中进行更改。由于此功能需要测试，因此将再次在Staging分支中将其拉出。从测试仪上注销后，我们将其推送到master分支。与您的工作流程相比，我们对master分支的提交较少，但是如果您对现有代码进行了任何更改，合并冲突仍然仍然存在。

Answer 4

在the presentation of GitFlow中可以看到，master是一个分支，始终是合并目标，而不是源。因此，正如您正确观察到的那样，master分支将包含其他分支没有的合并提交。根本没有问题，最多只是一个外观问题。

您为什么为此感到烦恼？如果坚持下去，您将拥有这些提交，但是为什么还要关心它们呢？它们不会以任何方式影响工作流程。

阻止Master Branch领先于dev

4 个答案: