git merge-继续--no-commit

如何解决git merge-继续--no-commit

是否存在不使用命令“ git merge --continue”提交的解决方法

我正在尝试与命令# git merge -q --no-commit --no-ff --no-edit origin/myBranch --progress -m "Auto merge"自动合并-如果没有冲突，则可以正常工作。

但是，当特定文件夹存在冲突时，我要从合并（git reset folderName中排除该冲突，然后发出一个# git merge --continue with --no-commit的命令

git merge --continue不再接受--no-commit（fatal: --continue expects no arguments）之类的参数

git merge --continue进行自动提交并在下面显示结果。

git status

    On branch program/XYZ
    Your branch is ahead of 'origin/XYZ' by 10 commits.
      (use "git push" to publish your local commits)

解决方法

您无法获得所需的内容，因为合并的唯一方法是提交。¹

要了解为什么会发生这种情况，请记住什么是提交和执行：

每个提交都有编号。这些不是简单的计数数字，它们不会去1、2、3等。但是它们是唯一的：每个提交都具有一个 hash ID ，其他提交可能没有。
每个提交存储两件事：Git知道的所有文件的完整快照，以及一些元数据，例如谁进行了提交，何时以及为什么（日志消息）。在元数据中，Git存储此提交的父母或父母的提交编号。

最后一部分-提交的父母-是Git中历史的工作方式。像master这样的分支名称仅仅保存分支中 last 提交的哈希ID：

... <-F <-G <-H   <-- master

Git可以从名称master中读取此哈希ID，并使用它在其所有Git对象的大型数据库中定位提交H。从此数据库中读取提交H后，Git会找到先前提交G的哈希ID。这使Git可以读取提交G，其中包含较早提交F的哈希ID，Git可以读取提交F，依此类推。 Presto：有历史。同时，每个提交都保存着每个文件的完整快照，因此通过比较G中文件的内容和H中文件的内容，Git可以告诉您什么在G和H之间进行了更改。

这处理简单的线性链，但是合并呢？在Git中，合并是通过合并提交实现的。合并提交定义为具有至少两个父提交的任何提交。

假设我们有以下内容：

          I--J   <-- branch1
         /
...--G--H
         \
          K--L   <-- branch2

您可能希望先执行git checkout branch1然后执行git merge branch2来合并两个分支，但是Git并不真正在意分支。 Git关心 commits 。合并过程的工作依据：

找到最佳的 shared 提交，在这种情况下为H；这称为合并基础；
将合并基础H中的快照与当前提交J中的快照进行比较，以了解“我们”的变化；
将合并基础H中的快照与另一个提交L中的快照进行比较，以了解“它们”发生了什么变化；和
组合更改，并将组合的更改应用于H中的快照。

（您可以认为这是在我们的更改之上应用它们的更改，反之亦然，但是在内部，Git只是将两组更改组合在一起，这意味着它需要将组合的更改应用于 base 版本H。）

成功完成所有这些组合后，Git通常继续进行新的提交，如下所示：

          I--J
         /    \
...--G--H      M   <-- branch1 (HEAD)
         \    /
          K--L   <-- branch2

请注意，新提交M既指向先前的当前提交J 又指向另一个提交L的。更新的分支名称与往常相同：当前分支名称。名称branch1现在指向新的合并提交M。

使用--no-commit，您指示Git在合并或未能合并两组更改之后停止。这使您处于这种状态：

          I--J   <-- branch1 (HEAD)
         /
...--G--H
         \
          K--L   <-- branch2

Git尝试将合并的更改应用于H的尝试是在两个位置之一或两者中找到的：

如果Git成功合并了某些文件 F 的更改，则文件 F 在Git的中处于阶段零。索引，并在工作树中对其进行修改以匹配索引副本。
如果Git在合并 F 的更改时失败，则文件 F 处于Git索引的非零阶段。在大多数情况下，²现在在索引中有三个 F 副本：第一阶段的一个来自提交H，第二阶段的一个为来自提交J，第3阶段来自提交L。同时，您的工作树包含Git尝试合并更改的尝试，但添加了冲突标记。

此时，git commit命令将：

如果任何索引条目不在零阶段，则失败，或者
进行新的合并提交（照常提交M）。

和往常一样，Git此时将使用索引中的任何内容进行新的提交。因此，git reset --mixed可以重置索引文件，您可以这样做。通常，最好使用git checkout（或在Git 2.23或更高版本中，git restore）来更新两者索引和如果是保留那些文件的一个特定提交版本，则执行一些提交。

您写了this in a comment：

重置命令-我正在重置为当前分支的原始状态/提交

为此，最好使用：

git checkout HEAD -- path

或：

git restore -iw --source HEAD path

，它将同时更新path中的命名 HEAD 的索引和工作树副本，并在此过程中清除较高级别的（合并冲突）条目。

当我做git merge --continue时，不应提交...

成功完成git merge --continue 的唯一事情就是提交。现在可以完成合并（因为已经清除了所有更高阶的条目，索引已准备好提交，而准备就绪的阶段零条目将其替换），并且git merge --continue将运行git commit，这将执行进行提交，或满足以下两个条件之一：

仍然存在一些较高级别的条目，并且无法进行提交（git commit也将失败）。或者：
您完全中止了合并，因此没有要继续的合并（git merge --continue将失败，但是git commit将尝试进行新的提交）。³

¹快进合并根本不是合并，而且无论如何您都将--no-ff排除在外。

²这掩盖了存在修改/删除，重命名/删除以及其他此类高级冲突的情况，因此出现了大多数情况。

³请注意，git commit（无论是否提交合并）都可能由于其他原因而失败。例如，您可能有一个拒绝提交的预提交挂钩，或者您的磁盘驱动器着火了。如果当前索引与当前提交匹配，则常规（非合并）提交通常会失败：Git将此尝试进行 empty 提交。请注意，您可以使用--allow-empty强制提交，这样的提交实际上并不是 empty：，它仍然具有每个文件的完整快照。只是新提交中的快照与上一次提交中的快照完全匹配，这使Git怀疑您为什么要打扰。

git merge-继续--no-commit

如何解决git merge-继续--no-commit

解决方法

相关推荐