分层项目的git

有不同的版本库repoA，repoB和repoC每个尊重相同的目录布局的原则，将被合并到第三repoM的工作目录（“主”项目）。

repoM有一个非典型的设置（--work-dir和--git-dir是sepparate）。 repo [A-C]被克隆为裸露，并且它们被设置为core.bare = false和core.worktree=<--work-dir-of-repoM>。

的要求：

我需要始终有一个概述了在repoM的工作目录中的所有文件，这些文件可以从回购[A-C]朵朵的历史。用这种方法，我会失去所有的信息。

备选：

我一直在想使用Git树代替（git version 1.7.11.2，所以它已经内置），留下回购[AC]裸露，然后

git pull -s subtree ，或
git subtree ...

随着子树拉动战略，我失去了合并冲突的历史（git blame如此说）。

我以前从来没有使用过子树，但是从我的理解来说，无法将从repo [A-C]中的文件合并到repoM的工作目录中，这些文件必须放入repo [A-C]的子目录中。这绝对不是我所需要的。 为什么？因为以下的原因...

问题陈述：

你有不同的Git仓库每个包含不同的文件集，通常配置文件和一些shell脚本。您希望将所有这些存储库中的所有内容都放入$HOME（即<--work-dir-of-repoM>）目录中。您应该始终能够看到每个文件的来源，编辑，提交并将更改推送到每个文件的origin。你已经猜到了，它有点类似vundle，但推广到任何程序的任何配置，而不仅仅是vim捆绑。如果发生冲突，应该能够追踪同一文件的哪两位作者需要彼此联系并达成协议（如果需要的话）。

这是一个开源项目，我试图让一个原型的工作，所以任何帮助，高度赞赏。关于已经存在的以类似方式做到这一点的项目的想法也受到高度赞赏。

注意：“主目录”并不一定是$HOME，我用它作为可能解决的问题的一种可能的提示。

来源

2012-08-05 Flavius

为什么子树的复杂性？为什么不以你想要的任何[集成管理器]工作流的方式来对待这个问题？ – Christopher 2012-08-06 03:52:36

@Christopher考虑到需求暴露，我刚刚列出了我尝试过的东西。你的提案如何符合这些要求？ – Flavius 2012-08-06 14:11:21

我其实不太清楚我的理解你的要求，因此我的问题。这听起来像是你有三个回购站，它们以较小的方式派生出一个有福的仓库，它应该包含来自三者中每一个的所有变化。这是准确的还是有一些复杂的，我没有看到（完全可能）？ – Christopher 2012-08-06 14:31:45

为什么不简单地在您的“主项目”中使用Git Submodules？

来源

2012-08-06 12:57:01

我必须引用自己的这一点：*这些文件必须放入repo子目录[A-C]。这绝对不是我所需要的。* – Flavius 2012-08-06 13:05:02

他们是否绝对需要_must_共享相同的根目录？所有存储库是你控制的还是他们是_independent_ projects？ – 2012-08-06 13:17:28

是的，这是绝对的要求。这是必须做的事情。他们在某种程度上是独立的，但他们不知道如何尊重特定的目录布局，因此可能会发生冲突。你是一个Linux用户？如果你是，你会从**问题陈述**中理解它的含义。 – Flavius 2012-08-06 13:22:28

分层项目的git

回答

相关问题