新产品变体的 Git 分支

Question

我正在使用 git 来管理我正在处理的存储库。

master 分支是“主”项目。但是，我也在研究与主产品相似但又不相同的并行产品。它位于一个名为 newproject 的分支中。

两者的代码库非常相似，但newproject 更加精简，并且有一些核心变化。然而，在这两个分支之间，大量的装饰材料，如 CSS、javascript 等是相同的。

另一方面，我已经删除了newproject 分支中仍然存在于master 中的许多文件。

我不想将这些项目重新合并在一起，就像典型的分支情况一样，您创建一个分支以添加功能或修复错误，然后合并回master--这些分支将永久独立存在.

但是，我仍然希望从master 到仍然存在重叠/共享文件的newproject 进行任何修复。

如果我只是这样做

$ git checkout newbranch
$ git pull origin master

我遇到了一大堆冲突，因为所有已删除的文件都显示为冲突，因为它们仍然存在于 master 中。

有没有办法处理这种情况？

Answer 1

git 子模块实现的效果正是你想要的：多个项目依赖的公共代码主体，修复了所有依赖项目之间共享的公共代码。子模块通过分离共享代码的历史来实现效果，但这只是机制——一旦你看到它，你就会明白它是自然正确的解决方案。

子模块命令本身的存在是为了跟踪一些挑剔的内务细节（通常，您可以在 repo 中 rm -rf * 并且不会丢失任何已提交的状态，但对于嵌套 repos 则不是这样，因此该命令通常会提升子模块 .git dirs ; 类似的东西），但子模块本身只不过是一个具有自己历史的嵌套存储库。如果你 cd 进入它，git 命令甚至不知道它是任何东西的子模块，因为它们不必关心：作为子模块只是 repo 的使用方式，而不是 repo 本身固有的任何东西。

  git init projectA
  cd projectA
  touch A            # now there's a file at the projectA root,
                     # but the projectA repo doesn't know about it
  echo 'this content is in file "A" at the projectA root'> A
  git add A          # content recorded, the index points to it
  git commit -m'A'   # now projectA repo has a permanent record of the indexed state


  git init projectInner  # now there's an entire repo at the projectA root,
                         # but the projectA repo doesn't know about it 
  cd projectInner
  echo "Inner content" > Inner   # a file at the inner repo, no repo knows about it
  git add Inner                  # content recorded, the inner repo's index records it
  git commit -mInner             # the inner repo has a permanent record


  cd ..
  git add projectInner   # now the projectA repo knows about the inner, the content is recorded ...
  git commit -mInner     # and now the projectA repo has a permanent record

git add实际的repo就是记录它的当前状态，就像添加一个文件或一个目录一样，但是文件的记录状态是它的全部内容，而目录的记录状态是递归状态在其所有（跟踪或未忽略的）内容中，repo 的记录状态只是其 HEAD 提交的 SHA——其他所有内容都已记录在该 repo 本身中。

这里的有效负载是 git 子模块只是一个嵌套 repo，事实证明嵌套 repo 可能是一个非常有用的东西。与 git 的其余部分一样，子模块命令实际上做的事情非常简单，所有明显的复杂性都在于在它非常有用的所有不同情况下实现最方便的东西。

Answer 2

分支后，您将能够在新项目分支上执行git rebase master，将其分离点向上移动到主分支的HEAD。这将做的是从newbranch 分离点重新应用所有差异（这将非常容易并且可能没有重大冲突，如果有的话，因为大多数文件不再在newproject 分支中）在对主分支所做的更改之上。由于newproject 提交包括删除这些文件和其他更改，所以一切都应该顺利进行（希望不会有太多冲突）。查看此处链接的事实上的 git 书下列出的 rebasing info。