git - 如何在不 merge 或 rebase 的情况下解决分支上的 git 冲突

Question

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

• 分公司
• 做出改变
• 变身掌握
• 推送并制作 github pull 请求 (PR)
• 做出更多改变
• 其他人审查代码并单击 github merge 按钮

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

1. 一个很好的 diff，没有 merge 提交和/或来自 master 的随机更改
2. 我的冲突解决方案
3. 他们可以点击的 merge 按钮

但是，我可能不想 rebase ，因为代码审查已经在进行中(有时我无论如何都会 rebase ，但其他时候我想避免它)。

我怎样才能可靠、高效地使用 git 来实现这一目标？

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

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

有时这不起作用，因为冲突是空的，所以我不知道要注释什么才能找到正确的提交。 编辑:事实上，在空冲突的情况下，我想它是没有 merge 或 rebase 就不可能解决(但在其他情况下是可能的——见下面的例子)。

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

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

这是一个具体的工作示例，因为这里的答案存在怀疑，有时可以像我在这里描述的那样解决分支上的冲突而无需 merge 或 rebase (请注意，这并没有显示上面工作流程的每个步骤，并仅演示“在没有 merge 或 rebase 的情况下解决分支上的冲突”部分):

$ 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 中选择了不同的分辨率，我将无法使用该 merge 命令进行 merge (这至少类似于 github merge 按钮所做的)。在那些情况下，通常我要么自己进行 merge ，要么进行 rebase ——但这不是这个问题的目的(尽管如果有某种方法可以实现 merge 按钮的可点击性，而无需在这些情况下 merge master 或 rebase ，那会很有趣听说!)。

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. 当我将功能分支 merge 回 master 时，我遇到了一些小冲突。如果从 master merge 到功能分支，这些冲突要小得多。事实上，您可以这样做:

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

   它应该可以工作。但是，这可能意味着 GitHub Merge 按钮不起作用，而且我认为没有办法告诉 GitHub 使用 -x theirs。

   我不确定这是否仅取决于所做的相对更改，所以这可能只是由我的特定测试 repo 引起的问题。

2. 如果您有依赖于 aaa 的提交 bbb，都在 master 上，然后是 bbb 的 cherry-pick 将被检测为冲突。我的测试表明，无论您是在 cherry-pick 中保留这样的更改还是丢弃它都没有关系。 (它似乎也不会影响问题 #1。)

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