将远程拉入子目录

Question

我有一个托管在bitbucket上的Git存储库,它具有以下目录结构:

/Automation
/Website
/Website/   <-- [WebsiteFilesGoHere]
/Dependencies
/WebServices

我们有一家供应商正在构建/Website解决方案的一部分.

他们有一个看起来像这样的回购

/    <-- [WebsiteFilesGoHere]

什么是将他们的repo拉入我们的子文件夹,然后能够在以后推迟的最佳方法？

更新:值得一提的是,两个repos都有当前`/ Website'文件夹中的文件而不知道彼此.

更新2:这也是一个基于Windows的Git仓库,由许多开发人员共享(因此避免任何本地机器配置都会很棒).

Answer 1

有一种方法可以在不使用子模块或子树的情况下引入远程存储库,即使该存储库与您的存储库完全无关并且具有冲突目录.

首先,将该存储库添加为您的某个遥控器.git/config.例如,假设您想从Github引入Zaldor的Gruff库.这些名字完全是虚构的:

[remote "gruff-upstream"]
fetch = +refs/heads/*:refs/remotes/gruff/*
url = https://github.com/zaldor/gruff.git

现在你可以做一个git fetch gruff-upstream来获取所有对象.现在,您可以在gruff项目中看到可用的分支.

$ git branch -r
gruff/experimental-hack
gruff/master
origin/master

这两条gruff线是gruff分支.这origin/master是我们自己的起源.名字冲突:gruff有一个master,我们也有master.这没关系:我们可以给出gruff/master不同的本地分支名称.

$ git branch -t gruff-master gruff/master
Branch gruff-master set up to track remote branch master from gruff-upstream.

现在,如果我们git checkout gruff-master,我们所有的git跟踪文件都会消失,取而代之的是gruff工作副本:

$ git checkout gruff-master

现在我们可以gruff-master稍微梳理一下这个分支.例如,我们可以将其所有文件移动到子目录,删除不需要的文件等:

$ mkdir gruff
$ git mv ...files... gruff
$ git commit -a -m "moving gruff stuff to gruff/ subdir"

接下来,我们切换回自己的master.Gruff文件消失了,我们的文件又回来了:

$ git checkout master

现在我们可以将一些文件gruff带入我们的master:

$ git checkout gruff-master -- gruff/file1 gruff/file2 ...

这些文件在我们的工作副本中实现,并添加到我们的索引中:

$ git checkout
A gruff/file1
A gruff/file2
...

我们可以把这些提交到我们master现在.

当上游gruff发布文件的新版本时,我们可以切换到我们的gruff-branch拉动.根据我们的清理和提交解决新的更改.回到我们的网站master,我们可以从我们gruff-master当地的跟踪分支机构中挑选出新的更新.

是的,这基本上是使用Git作为一个美化的补丁工具.gruff-master拾取的材料master没有任何血统; 它看起来像添加文件.然而,它总比没有什么好,并且在很多方面比子树或模块更不麻烦.

Answer 2

通常建议最好使用子树而不是子模块

\n

这里有一个很好的好处：

\n

http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/

\n

\n

您可能会发现子树更好用的原因有几个：

\n

简单工作流程的管理很容易。

\n

支持旧版本的 git（甚至在 v1.5.2 之前）。

\n

超级项目克隆完成后，子项目\xe2\x80\x99s 代码即可使用。

\n

子树不需要您的存储库的用户学习任何新内容，他们可以忽略您正在使用子树来管理依赖项的事实。

\n

子树不会像子模块 doe（即 .gitmodule）那样添加新的元数据文件。

\n

可以修改模块的内容，而无需在其他地方拥有依赖项的单独存储库副本。

\n

在我看来，缺点是可以接受的：

\n

您必须了解新的合并策略（即子树）。

\n

为子项目向上游贡献代码稍微复杂一些。

\n

在提交中不混合超级项目和子项目代码的责任在于您。

\n

\n