避免合并提交的一个标准方法是使用rebasing代替合并。考虑以下场景：

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上 rebased 你的分支，你会得到：

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 merge提交。事实上，featureMy分支和master都有 * 相同的 * 线性历史。
万岁git rebase。

如果您的合并冲突可以通过完全使用文件的一个版本来解决，那么这里有一个解决方案。
假设你想合并到一个名为qa的分支中，而composer.json和composer.lock中存在冲突。qa包含您想要使用的更新版本，而不是您的分支中的版本。

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

字符串