Question

我只想知道，如果有任何办法，解决两个git分支的合并提交，而不实际合并它们。

假设我有一个分支“featureMy”;我的同事创建了另一个分支“featureHis”。两个分支都在“主”分支上创建。

我的同事然后为他的分支“featureHis”创建了一个合并请求到主人。当我然后将“featureMy”的合并请求创建为master时，我想确保在“featureHis”合并后它不会与master发生冲突。

通常，我之前会将“featureHis”合并到“featureMy”中。但是，这并不令人满意，因为我有一个额外的合并提交作为“噪音”，我的合并请求将包含来自“featureHis”的更改。

有没有办法，这样我就可以解决合并冲突，而无需创建合并提交？

亲切的问候

Answer 1

避免合并提交的一种标准方法是使用rebase代替合并。请考虑以下情形：

master:     A
featureMy:  A -- B
featureHis: A -- C

假设master只存在这两个分支，那么你们中的一个将首先与master合并。让我们说是你的同事首先到达那里。然后图表看起来像这样：

master:     A -- C
featureMy:  A -- B
featureHis: A -- C

您同事的提交现在位于master分支机构中。现在，如果您使用基于合并的工作流，则首先将master合并到分支中，然后将分支合并回master。这将导致：

master:     A -- C -- E
featureMy:  A -- B -- D
featureHis: A -- C

现在你的分支和 master分支都有丑陋的合并提交。但是，如果你在master上重新定位你的分支，那么你将会留下：

master:     A -- C
featureMy:  A -- C -- B'    (B' indicates that this a new commit, not B)
featureHis: A -- C

现在，您的分支featureMy实际上是master分支的提前。您可以直接在master之上直接推送您的提交，而不会发生冲突。这导致下图：

master:     A -- C -- B'
featureMy:  A -- C -- B'
featureHis: A -- C

请注意，任何地方都有 no 合并提交。实际上，您的featureMy分支和master都有相同的线性历史记录。

万岁git rebase。

Answer 2

如果可以通过完全使用一个文件的版本来解决合并冲突，那么请采用以下解决方案。

假设您要合并到名为qa的分支中，并且composer.json和composer.lock中存在冲突。 qa包含您要使用的更高版本，而不是分支中的更高版本。

git checkout origin/qa -- composer.json composer.lock
git commit -m "fixed merge conflicts without merging"