Question

我正在开发基于Eclipse Foundation的基于JGit的Git插件，并且我的同事已经实现了“ 重新启动合并”，用于在尝试执行默认请求时发生冲突（带有合并）。

现在，我正在执行“ 拉（变基）”操作。当发生冲突并且用户在冲突文件中进行了一些更改时，我希望让他们能够重新启动合并。我注意到有些Git客户端没有此选项（例如Eclipse的EGit，GitKraken Free），而有些则没有（SourceTree）。

我当前的代码如下：

public void restartMerge() {
    try {
      RepositoryState repositoryState = getRepository().getRepositoryState();
      String revision = repositoryState == RepositoryState.REBASING_MERGE ? "HEAD" : "MERGE_HEAD";
      AnyObjectId commitToMerge = getRepository().resolve(revision);
      git.clean().call();
      git.reset().setMode(ResetType.HARD).call();

      if (repositoryState == RepositoryState.REBASING_MERGE) {
        // TODO: regenerate the conflict
      } else {
        git.merge().include(commitToMerge).setStrategy(MergeStrategy.RECURSIVE).call();
      }

      fireFileStateChanged(new ChangeEvent(GitCommand.MERGE_RESTART, Collections.<String> emptyList()));
    } catch (IOException | NoRepositorySelected | GitAPIException e) {
        if (logger.isDebugEnabled()) {
            logger.debug(e, e);
        }
    }
}

我想我必须再次进行基础调整或类似的工作以重新产生冲突，就像我的同事做了一个新的merge()一样。但是此时，我处于一个独立的HEAD上...我尝试移至master分支，并再次以origin/master作为上游重新设基，但这没有用...

重新启动基线冲突的Git命令是什么？也许我可以使用JGit执行它们...

Answer 1

您可以尝试运行git rebase --abort，并根据情况使用git pull --rebase重新启动基准。

Answer 2

如您所见，git pull基本上是：

运行git fetch
然后运行第二个Git命令，通常但并非总是git merge

合并会因冲突而停止。您可以允许用户解决冲突并继续进行操作，也可以中止合并并将一切恢复到合并开始之前的状态：

要允许用户在手动解决冲突后继续操作，只需调用git merge --continue或git commit：git merge --continue本身会验证正在进行的合并中是否存在冲突固定，然后调用git commit。
要中止并将内容放回获取但合并之前的状态，可以使用git merge --abort或git reset --merge（它们执行相同的操作）。

不过，第二个命令可以是git rebase，它也可以因冲突而停止。在某些特殊情况下，甚至可以是git read-tree。因为在使用git pull时您几乎没有控制权，所以我建议您从不以编程方式使用它：如果您要编写运行Git命令的代码，则总是将您的操作添加到git fetch和您自己的以编程方式选择的第二个Git命令中，以便您知道要运行的第二个命令。

不过，变基的问题在于，它实际上是由一系列git cherry-pick操作构成的。（取决于您调用git rebase的方式，实际上它可能是git apply --3way而不是git cherry-pick，或者实际上是运行git cherry-pick。）每个樱桃-pick操作可以因合并冲突而停止。因此，您不仅有一个冲突，而且还有 M 个冲突， M≤N ，其中 N 是要复制到其提交中的提交数重新设定新职位。

要在用户解决冲突后恢复基准，请调用git rebase --continue。这可以验证是否存在正在进行的重新部署，并且冲突已得到解决，然后提交并继续进行下一个“自动选择”操作。重新设定将继续进行，直到遇到另一个合并冲突，或者完成了所有的重击操作为止。完成最后一个选择之后，重新设置基准将分支名称的值重新分配给最后复制的提交，并将HEAD重新附加到分支名称。

如果您使用git rebase --abort，则告诉Git停止进行摘樱桃的操作（包括所有尚未开始的操作），并返回到 any 之前的状态他们开始了。如果允许用户解决合并冲突，请注意，这会丢弃 all 到目前为止解决的所有问题，包括用户为解决冲突所做的所有工作。如果用户启用了git rerere，则已解决的到目前为止的合并结果将记录在重用缓存中，因此并不总是那么糟糕。

并没有解决合并冲突的好方法。如果有办法可靠地自动执行此操作，那么Git会做到的。

如何为“ pull --rebase”冲突重新启动合并

2 个答案: