我有一个分支A，文件夹名为foo。另一个名为B的分支仅包含文件夹的内容foo。是否可以将分支B合并到分支A的文件夹foo中？
分支A包含例如
foo/
hello_world.c
goo/
AliceAndTom.c
分支B仅包含文件夹foo /的内容
./
hello_world.c
hello_world.h
合并分支B后在分支A中获得的结果：
foo/
hello_world.c
hello_world.h
goo/
AliceAndTom.c
编辑：分支B是使用git命令创建的git filter-branch --subdirectory-filter dir/to/filter -- subdir_branch
您不能直接将其合并。
关于git的重命名检测在这里是否有帮助的评论中有些混淆。根据您所说的创建分支（使用filter-branch）的方式，很可能不会创建分支。这是因为新分支可能与旧分支没有共同的祖先。[1]
因此，首先您必须解决让git从分支识别相应文件的问题；然后您必须解决以下问题：对于该文件的两个当前状态，它仍然不知道最新的共同祖先，因此合并将无法顺利进行。（两个分支上都存在的每个文件很可能会在整个文件上发生冲突，而不会真正合并任何文件。）
这是由于“不同分支上的内容不同”而引起的问题之一；这不是git的工作原理，它可以使跨分支的更改集成变得非常乏味。
自filter-branch运行以来，这将是多么繁琐取决于每个分支上文件的更改量。我能想到的最通用的过程是：
（1）编写脚本，将文件移回其子目录
（2）filter-branch在较新的分支上运行（使用上面的脚本作为树过滤器），创建另一个分支，其结构更接近原始分支
（3）确定新分支中与原始分支中的提交相对应的最后一个提交
（4）用于git replace代替上面提到的提交来代替原始分支中的相应提交。
（5）现在，您应该能够将新分支合并到原始分支。然后，您可以撤消git replace并可能处置新分支。
有关每个步骤的详细信息，请参阅。这不是一个简单的过程，因此，如果要继续使用它，请参考相关命令的文档。
[1]-更具体地说，要应用重命名检测，git必须查看一个既删除文件又创建具有足够相似内容的另一个文件（位于不同路径）的补丁。
如果您从分支开始master，然后在分支上进行了提交，以移动文件，那么现在您将看到类似
x -- x -- O -- A <--(master)
\
x -- x -- B <--(bramch)
合并branch到时master，git将查看O和之间的修补程序，该修补程序B满足重命名检测的条件（只要移动的文件变化不大）。
但是filter-branch可能创造了一个完全独立的历史
x -- x -- x -- A <--(master)
x -- x -- B <--(branch)
默认情况下，合并将失败（没有共同的历史记录），如果您使合并没有失败（通过说允许不相关的历史记录），则合并的作用就好像合并基础为空TREE（即没有文件）。从补丁到A创建foo/file，并从该补丁，以B创建file，但是没有打补丁的一条路径都删除该文件并创建它的其他，所以重命名检测不会发生。合并将创建文件的第二个副本。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句