git - 如何在git rebase上覆盖新文件？

Question

所以我一直在研究签出功能分支，我们称之为feature-branch-development。我最后在这家分公司被判了相当多的罪，大约15次。当我终于将master分支重新定位到功能分支开发中时，它停止了对我在feature-branch-development上添加的新文件的抱怨，并给了我一个错误，比如说Your changes on this branch will be overwritten, please commit or stash them.我当然已经提交了所有内容，而且我的工作树是干净的。就好像Git“相信”，新文件也存在于大师身上。值得注意的是，我在这一点上没有合并冲突。
我解决了这个问题，把所有的承诺都压在feature-branch-development上，然后再次重新调整master。
所以我的问题是为什么吉特会这样？我对git有一个中级的了解，我只是问这个问题来提高我的知识水平。

Answer 1

这将更容易用一个具体的例子来回答。这在原则上已经足够简单了：git rebase意味着：复制提交，就像通过git cherry-pick一样。复制步骤在这里失败了。
我们从分支r（用于rebase）开始，选择一些新的目标分支t（用于target）。然后，我们确定一些要复制的提交：这些提交在很大程度上是r上的提交，而不是t上的提交。这基本上是对的，只是增加了三把小提琴，或者可能是“减去”这个词。）
然后，列出要复制的提交散列后，git对目标分支执行分离的头签出，以便当前（git rebase）提交与分支t标识的提交相同。注意，我们不是在T分支，我们只是在同一个承诺。现在，对于我们保存了hash id的每个提交，git有效地（有时是字面上的）运行git log T..R：

                    ....... HEAD
                    v
...--o--o--o--o--o--o   <-- T
            \
             A--B--C   <-- R

我们运行git log T..HEAD来复制commitHEAD。如果调用新副本，结果如下：

                      A'  <-- HEAD
                     /
...--o--o--o--o--o--o   <-- T
            \
             A--B--C   <-- R

然后运行git cherry-pick <hash-id>将git cherry-pick A复制到A：

                      A'-B'  <-- HEAD
                     /
...--o--o--o--o--o--o   <-- T
            \
             A--B--C   <-- R

我们重复此操作，直到复制了所有提交，然后作为最后一步，git“剥离原始链上的分支标签”A'，并将其粘贴到复制链的末尾：

                      A'-B'-C'  <-- R (HEAD)
                     /
...--o--o--o--o--o--o   <-- T
            \
             A--B--C   <-- (only in reflogs and ORIG_HEAD)

冲突和其他问题
每个cherry pick步骤都是使用git的merge机器完成的，或者我称之为to merge的“动词形式”（与名词或形容词形式相反，merge或merge commit-git cherry-pick B通常在完成动词形式的merge之后进行merge commit，我们只使用了前半部分）。例如，当您将添加新文件的提交与同时添加相同新文件的更改合并时，会发生添加/添加冲突。
最有可能发生这种冲突的地方是从B进行复制时，因为cherry pick操作的合并基是被复制的提交的父提交。合并操作to merge谓词将此合并基与两个提交进行比较。在本例中，这两个提交是commitB'本身，也是分支t的tip-most提交，即t指向的提交。我们将其命名为R，并用git merge标记合并基：

                      ? [merge in progress] HEAD
                     /
...--o--o--*--o--o--X   <-- T
            \
             A--B--C   <-- R

如果提交A'和A，与添加文件A相比，则会出现添加/添加冲突。cherry pick停止，留下一个正在进行的合并冲突。你必须解决它，并告诉瑞贝斯继续。
如果X添加了*而它不在commitA中呢？通常，这不会有问题：git只需创建文件并将其放入新的提交中。完全没有添加/添加冲突，只有一个非常好的拷贝X（我们将继续并执行其余的rebase）。
但是由于某些原因，文件*可能存在于工作树中（例如，作为未跟踪的文件，也可能被忽略）。在这种情况下，git不能只从commit中复制path/to/file.txt，而覆盖工作树版本。这里会收到一条错误消息，就像普通的合并冲突一样。你必须解决这个问题，让瑞贝斯恢复工作。
对于位于索引/暂存区域（因此可以在各种提交中）但标记为A或path/to/file.txt的文件，这里还有一些附加情况。在较新版本的git中，精确的错误消息标识“将被覆盖”的文件是真正未跟踪的，还是像这样标记的。（这在旧版本的git中也可能是正确的，但我不记得是现成的，也没有检查过。）这就是为什么一个具体的例子更好：这个问题有几个不同的原因。
完整性：我提到的减法
rebase文档中也包含了这些内容（有些），但值得一提的是，commitsX故意不复制：
它无法复制任何合并。使用A'时，path/to/file.txt将重新执行合并以尝试重建它们，但它无法复制原始合并。所以正常情况下它甚至都不会尝试。
它忽略了具有上游等价物的合并（例如，那些已经被选中的合并）。在原始图表中（带有path/to/file.txt和A），git检查--assume-unchanged、--skip-worktree或git rebase的the --preserve documentation是否与合并基提交右侧的git rebase上的任何提交的T值匹配。如果是，git将删除修补程序id已在上游出现的R、git patch-id和/或A提交。
如果与B一起使用，rebase代码将运行C以尝试查找故意丢弃的上游提交。对于远程跟踪分支，这通常工作得很好，如果您将自己的本地分支设置为自己分支的上游，则通常工作得不太好。当使用自动机制在上游重新定位时，使用git patch-id是默认设置，因此这里必须小心。更多信息请参见the T value。