如何在本地解决git冲突（有一些限制）？

Question

我想解决 git 合并冲突（feature 和 test 分支之间），但有一些限制：

1. 无法直接推送到test和master分支
2. 无法将 feature 分支合并到 test 分支（因为我无法推送到 origin test）
3. 无法将 test 分支合并到 feature 分支（因为稍后，当测试时我应该将 feature 分支合并到 master 分支）
4. 冲突是由 test 分支引起的，而不是 master 分支
5. 我想避免重复分支
6. 无法解决 Gitlab UI 上的冲突，因为它在解决后将目标分支（test）合并到源分支（feature）

我团队的工作流程如下：

• 每个feature分支必须基于master分支
• 提交/推送feature分支，然后创建一个合并请求到test（default）分支（然后等待测试）
• 创建一个到 master 分支的合并请求

我尝试了这些解决方法：

1. 暂时关闭“反推”约束（如果有很多冲突，这并不理想）
2. 永久关闭“反推”约束（我不想要这个......）
3. 使用重复的分支（我不想要这个，因为它很混乱）
4. 使用 Gitlab UI（破坏我的工作流程，如上所述）
5. 手动编辑功能分支（不起作用，因为它不是“真正的”合并）

我想我不能使用

git rebase

，因为冲突不是由master分支引起的，而且我想保留“基于master”的功能分支，所以我也不能使用基于test分支的rebase。

在少数情况下，这个解决方案可以解决问题，但在我的情况下不行。

我正在寻找一个“简单”的解决方案来解决上述问题。 本地临时分支（但远程不行）是可以的。

Answer 1

没有简单的解决方案来解决合并冲突；你必须手动解决它们，否则 git 会帮你解决的。

暂时忘记你的限制。答案很简单。您可以将

test

合并到您的分支（本地）并解决冲突，然后再次推送到您的分支，或者从

temp

创建一个新的

test

分支，合并您的分支（再次在本地），解决所述冲突，然后然后将结果强制推送到原始分支并重新提交。两者之间的唯一区别是更改的方向性以及更改的显示方式以及您更喜欢的历史记录显示方式，以确保您的分支和

test 之间更改的最终结果

只是添加功能与

test

自您从

master

分支以来发生的变化兼容所需的内容。

工作流程和约束使得这基本上不可能，并且会让你不断失败，特别是规则＃3和工作流程规则＃1。那么，如果

test

合并到你的分支中，然后你将它合并回

test

，这就是 GIT 中的工作方式，这是一件健康的事情。

其次，如果所有内容在合并到

test

之前都必须进入

master

，那么你应该从

test

分支，而不是从

master

开始。

如果您的分支中存在冲突，那么在问题得到解决之前您无法合并到

test

。解决这些问题的唯一方法是执行我上面描述的两件事之一。

如果这些不是可以接受的解决方法，你应该去问谁制定或执行了这些规则，或者团队领导你到底应该做什么（如果他们没有一个好的答案并意识到他们所需要的不可能的愚蠢然后准备你的简历并开始寻找新工作）。

Answer 2

我仍然建议将

feature

分支重新定基到

test

：您可以稍后将结果重新定基到

master

（如果来自

test

的冲突功能也合并到 master 上，可能会更容易）。

另一方面，如果

test

分支中的冲突更改是临时的（即不会合并到 master），那么只需创建

feature

分支的副本（例如

feature-test

）并重新设置 该副本到

test

并进行您想要的测试。添加新提交时，您可以使用

feature

或

feature-test

，然后也将提交挑选到另一个提交中。