0

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

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

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

另一方面，我已经删除了newproject分支中仍然存在于master.

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

但是，我仍然想从仍然存在重叠/共享文件的地方master获得任何修复。newproject

如果我只是这样做

$ git checkout newbranch
$ git pull origin master

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

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

4

2 回答 2

1

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

子模块命令本身的存在是为了跟踪一些挑剔的内务细节（通常，您可以rm -rf *在存储库中并且不会丢失任何已提交的状态，但嵌套存储库并非如此，因此该命令通常会提升子模块 .git 目录；类似的东西），但是子模块本身只不过是一个具有自己历史的嵌套存储库。如果你 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 意味着记录它的当前状态，就像添加文件或目录一样，但是文件的记录状态是它的全部内容，而目录的记录状态是它所有（跟踪或un-ignored) 内容，repo 的记录状态只是其 HEAD 提交的 SHA——其他所有内容都已记录在该 repo 本身中。

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

于 2013-02-22T20:28:19.140 回答
0

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

于 2013-02-22T03:18:48.193 回答