Question

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

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

两者之间的代码库非常相似，但newproject更加精简，并且有一些核心更改。然而，大量的橱窗装饰品，如CSS，javascript等，两个分支之间是相同的。

另一方面，我删除了newproject中仍然存在的master分支中的大量文件。

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

但是，我仍然希望从master获取任何修补程序到newproject，其中仍有重叠/共享文件。

如果我只是做

$ git checkout newbranch
$ git pull origin master

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

有办法处理这种情况吗？

Answer 1

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

子模块命令本身用于跟踪一些挑剔的内务处理细节（通常，您可以在仓库中rm -rf *并且不会丢失任何已提交的状态，但嵌套的回购并非如此，因此命令通常会提升子模块。 git dirs;类似的东西），但子模块本身只不过是一个有自己历史的嵌套存储库。如果你进入它，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实际的回购意味着记录其当前状态，就像添加文件或目录一样，但是当文件的记录状态是其全部内容时，目录的记录状态是所有（被跟踪或未被忽略）内容的递归状态，回购的记录状态只是它的HEAD提交的SHA - 其他所有已经记录在该回购本身中。

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

Answer 2

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

Git为新产品变异分支

2 个答案: