如何在不合并或变基的情况下解决分支上的 git 冲突

Question

我通常的功能/错误分支工作流程是这样的：

• 分支
• 做出改变
• 变基为主
• 推送并发出 github 拉取请求 (PR)
• 进行更多更改
• 其他人审查代码并单击 github 合并按钮

假设无法点击 PR 上的合并按钮，因为我的功能分支现在与 master 发生冲突。在这一点上，我通常想解决与 master 的冲突，我想在我的功能分支上这样做，这样我就可以让正在审查我的代码的人看到：

1. 一个不错的差异，没有合并提交和/或来自 master 的随机更改
2. 我的冲突解决方案
3. 他们可以点击的合并按钮

但是，我可能不想变基，因为代码审查已经在进行中（有时我无论如何都要变基，但有时我想避免它）。

我如何可靠有效地使用 git 来实现这一目标？

我目前所做的是这些事情的混合：

• “只知道”需要挑选或改变什么来解决冲突（有时......）
• 试用合并 ( git merge master; (查看哪个文件有冲突，然后 git annotate 以找到相关的提交); git reset --hard origin/my-feature-branch; git cherry-pick <some commit>(或者可能手动进行一些更改); (重复))

有时这不起作用，因为冲突是空的，所以我不知道要注释什么才能找到正确的提交。 编辑：事实上，在空冲突的情况下，我想如果没有合并或变基是不可能解决的（但在其他情况下是可能的——见下面的例子）。

当它起作用时，似乎 git 可以以更自动化的方式帮助我完成很多工作。

我也试过git-imerge——这似乎不是专门为此目的而设计的，它也以未处理的异常退出。

这是一个具体的工作示例，因为这里的答案存在怀疑，即有时可以解决我在此处描述的分支上的冲突而无需合并或重新定位（请注意，这并未显示上述工作流程的每个步骤，并且仅演示“在不合并或变基的情况下解决分支上的冲突”部分）：

$ mkdir -p conflict-example/upstream
$ cd conflict-example/upstream
$ git init .
Initialised empty Git repository in /tmp/conflict-example/upstream/.git/
$ echo 'changed_only_upstream before' > changed_only_upstream
$ echo 'changed_only_downstream before' > changed_only_downstream
$ echo 'changed_in_both before' > changed_in_both
$ git add .
$ git commit -m 'initial'
[master (root-commit) 23040ea] initial
 3 files changed, 3 insertions(+)
 create mode 100644 changed_in_both
 create mode 100644 changed_only_downstream
 create mode 100644 changed_only_upstream
$ cd ..
$ git clone upstream downstream
Cloning into 'downstream'...
done.
$ cd downstream
$ git checkout -b downstream
Switched to a new branch 'downstream'
$ vim changed_in_both
$ vim changed_only_downstream
$ cat changed_in_both
changed_in_both before
downstream
$ cat changed_only_downstream
changed_only_downstream before
downstream
$ git commit -am 'downstream'
[downstream 6ead47f] downstream
 2 files changed, 2 insertions(+)
$ cd ../upstream
$ vim changed_in_both
$ vim changed_only_upstream
$ cat changed_in_both
changed_in_both before
upstream
$ cat changed_only_upstream
changed_only_upstream before
upstream
$ git commit -m 'upstream conflict' changed_in_both
[master e9ec7c5] upstream conflict
 1 file changed, 1 insertion(+)
$ git commit -m 'upstream non-conflict' changed_only_upstream
[master d4057e0] upstream non-conflict
 1 file changed, 1 insertion(+)
$ cd ../downstream/
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ git pull
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From /tmp/conflict-example/upstream
   23040ea..d4057e0  master     -> origin/master
Updating 23040ea..d4057e0
Fast-forward
 changed_in_both       | 1 +
 changed_only_upstream | 1 +
 2 files changed, 2 insertions(+)
$ git checkout downstream
Switched to branch 'downstream'
$ git merge master
Auto-merging changed_in_both
CONFLICT (content): Merge conflict in changed_in_both
Recorded preimage for 'changed_in_both'
Automatic merge failed; fix conflicts and then commit the result.
$ git merge --abort
$ git log --all --graph --pretty=oneline --abbrev-commit --decorate
* d4057e0 (origin/master, origin/HEAD, master) upstream non-conflict
* e9ec7c5 upstream conflict
| * 6ead47f (HEAD -> downstream) downstream
|/
* 23040ea initial
$ git cherry-pick e9ec7c5
error: could not apply e9ec7c5... upstream conflict
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
$ vim changed_in_both
$ cat changed_in_both
changed_in_both before
upstream
$ git add changed_in_both
$ git commit
Recorded resolution for 'changed_in_both'.
[downstream 7a4f7a7] upstream conflict
 Date: Sat Aug 27 14:41:13 2016 +0100
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log --all --graph --pretty=oneline --abbrev-commit --decorate
* 7a4f7a7 (HEAD -> downstream) upstream conflict
* 6ead47f downstream
| * d4057e0 (origin/master, origin/HEAD, master) upstream non-conflict
| * e9ec7c5 upstream conflict
|/
* 23040ea initial
$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
$ git merge downstream
Merge made by the 'recursive' strategy.
 changed_only_downstream | 1 +
 1 file changed, 1 insertion(+)
$ git log --all --graph --pretty=oneline --abbrev-commit --decorate
*   c036d60 (HEAD -> master) Merge branch 'downstream'
|\
| * 7a4f7a7 (downstream) upstream conflict
| * 6ead47f downstream
* | d4057e0 (origin/master, origin/HEAD) upstream non-conflict
* | e9ec7c5 upstream conflict
|/
* 23040ea initial

我相信如果我在cherry-pick中选择了不同的分辨率，我将无法使用该合并命令进行合并（这至少类似于github合并按钮的作用）。在这些情况下，通常我要么自己进行合并，要么进行变基——但这不是这个问题的内容（尽管如果有某种方法可以实现合并按钮的可点击性，而无需在这些情况下合并母版或变基，那将会很有趣听说！）。

Answer 1

这是一个完成这项工作的bash脚本：

#!/bin/bash

declare -a conflicts

echo "Detecting conflicts..."
for rev in `git rev-list HEAD..master`
do
  git cherry-pick --no-commit $rev > /dev/null 2>&1
  if [ $? -eq 1 ]
  then
    conflicts+=($rev)
  fi
  git reset --hard HEAD > /dev/null
done

for rev in ${conflicts[*]}
do
  git cherry-pick --no-commit $rev > /dev/null 2>&1
  echo "Commit $rev cherry-picked."
  read -p "Resolve conflicts, then press any key to continue: "
done

echo "Done cherry-picking! Commit your changes now!"

运行此脚本，每次出现提示时，解决文本编辑器中的任何冲突，然后git add从另一个窗口执行此操作。完成后即可git commit（按照提示）。

到目前为止，在我的测试过程中，我发现这个脚本存在两个问题：

1. 当我将功能分支合并回 时master，我遇到了一些小冲突。master这些冲突比从功能分支合并时得到的冲突要小得多。事实上，它们是这样的，你可以这样做：

   git checkout master
   git merge --no-ff feature/my-feature -x theirs
   

   它应该有效。然而，这可能意味着 GitHub 合并按钮不起作用，而且我认为没有办法告诉 GitHub 使用-x theirs.

   我不确定这是否仅取决于所做的相对更改，因此这可能只是我的特定测试存储库引起的问题。

2. 例如，如果您有一个bbb依赖于 的提交aaa，并且都依赖于master，则cherry-pick将会bbb被检测为冲突。我的测试表明，保留cherry-pick或放弃这样的更改并不重要。（它似乎也不影响问题＃1。）

我正在寻找这两个问题的解决方案，但这应该足以让您开始。