标签: git-subtree

Git使用子树或子模块来管理外部资源

我读了很多关于git子模块应该是多么可怕,但我不确定这是否只是那些觉得有限的人的呻吟,或者是否有严重的问题(特别是关于我的用例).

我只想将不同的回购包含在我的回购中

website/
 libs/
  js/
   fs-slides [external]
   fs-dialog [external]
Run Code Online (Sandbox Code Playgroud)

并且有可能轻松更新这些回购.据我所知,从回购中只包含一个文件是不容易的,对吧?(但没关系.)

我应该使用子模块吗?
或者它有什么问题吗?或者子树更容易吗?

git git-submodules git-subtree

20
推荐指数
1
解决办法
9522
查看次数

将更新合并到我的子树时,Git很困惑

我们之前在主存储库中使用了许多子模块,但是为了提高项目的可维护性,我们开始了一个实验分支,我们用子树替换它们.

这很好 - 但是现在当我试图更新其中一个子树时,它错误地将更新合并到一个完全错误的目录中,甚至不是一个子树.

分支"子树"包含实验分支的主存储库是:git://github.com/hugowetterberg/goodold_drupal.git

要从以下位置合并更新的存储库:git://github.com/voxpelli/drupal-oembed.git

通过执行合并:git merge -s subtree oembed/master

应将更新合并到的路径:sites/all/modules/oembed /

它们合并的路径:modules/aggregator/translations /

任何人都知道如何获得子树的更新或错误是什么?

git merge subtree git-subtree

19
推荐指数
2
解决办法
2565
查看次数

git-subtree拉动并发症

我们一直试图让git-subtree处理一个项目(使用git版本1.7.9.4)并且遇到了一些复杂问题.几个月前,其他人之前使用此命令添加了子树:

git subtree add --prefix=foo git@example.com:foo.git master
Run Code Online (Sandbox Code Playgroud)

现在已经有了实质性的变化foo,我们想要合并这些变化,最好将它们压缩.自导入文件以来,没有任何文件被修改过.

我已经尝试了三件事来尝试合并更改.

第一:

git subtree pull --squash -P foo git@example.com:foo.git master
Run Code Online (Sandbox Code Playgroud)

抛出异常: Can't squash-merge: 'foo' was never added.

第二:

git subtree pull -P foo git@example.com:foo.git master
Run Code Online (Sandbox Code Playgroud)

这有点工作(但有一些问题,但是存在拉入所有提交的问题,并且与已修改的文件有冲突.

最后,我尝试了这个:

git pull --squash -s subtree git@example.com:foo.git  master
Run Code Online (Sandbox Code Playgroud)

这给了我想要的结果,输出Automatic merge went well; stopped before committing as requested和所有文件显示为已修改(具有正确的内容).

理想情况下,我想继续使用第一个git-subtree版本并获得接近上一版本的输出.如果我们必须始终使用最后一个版本,我们会,但我有点困惑为什么最后一个不产生合并冲突,而中间版本.

任何帮助表示赞赏.

git merge git-subtree

19
推荐指数
1
解决办法
1万
查看次数

合并子树更改 - 致命:无效路径'somefile_BASE_20704.cs'

我有三个回购 - 名称已更改为清晰:

SharedStuff,ProjectAProjectB

这两个项目都使用git-subtree来维护本地副本SharedStuff.他们都进行了本地更改,我正在尝试集中合并,测试,然后再次合并到每个.

我在ProjectA回购中运行了这个:

git subtree split --prefix=SharedStuff -b SharedStuff_from_ProjectA --rejoin

...然后将其推送到SharedStuff回购,解决了一些简单的冲突,将其合并.

现在我在ProjectB repo上运行它:

git subtree split --prefix=platform/SharedStuff -b SharedStuff_from_Project_B --rejoin

......然后又把它推到了SharedStuff一个新的分支中.当我尝试合并这些更改时,会出现问题.

在当前的情况下,我切换到SharedStuff_from_Project_B分支,然后git merge master- 但我立即将所有更改的文件列为添加/添加冲突.当我运行时git mergetool,每个人都有这样的错误:

Merging:
somefile.xyz

Normal merge conflict for 'somefile.xyz':
  {local}: created file
  {remote}: created file
fatal: invalid path './somefile.xyz_BASE_20704.cs'
Run Code Online (Sandbox Code Playgroud)

(当然,如果我尝试相反的方式 - 合并SharedStuff_from_Project_Bmaster- 我得到相同类型的冲突,只是逆转.仍然添加/添加).

我的猜测是ProjectB的历史可能有问题,导致添加/添加的外观.不过我不确定如何进一步诊断 - 我该怎么办?

编辑:之前有一个子树"rejoin"提交ProjectB,但SharedStuff …

git git-merge git-subtree

19
推荐指数
1
解决办法
606
查看次数

使用Git和Magento的最佳实践?

我正在努力弄清楚如何在我自己的回购中为自定义代码进行最佳工作,同时与供应商的库(在本例中为Magento)集成.在我的情况下,我不需要将补丁推送到供应商(虽然这将是一个很大的附带好处).

我查看了git子模块和git子树.我不认为git子模块可以满足我的需要.Magento具有以下类型的树结构:

/app
  /code
     /community *
     /core
     /local *
  /design
     /adminhtml
     /frontend
        /base
        /yourtheme *
/lib
  /Zend
  /Varien
  /yourlib *
/js
  /yourjs *
  /varien
  /mage
Run Code Online (Sandbox Code Playgroud)

使用git子模块似乎在单独的文件夹中效果最好(例如/是你的app和/ vendor/magento是子模块).然而,由于这种程度的交织,子模块似乎不是一个好的解决方案.我错了吗?

这让我失去了git子树.但是使用git子树,相同的核心假设(供应商分支,如名称所暗示的,一个子树)并不成立.Magento不是一个子树,而是我的项目适合的核心库.那是对的吗?

如果这两种git方法不起作用,那么我应该知道的其他方法会做我想要完成的事情吗?

我不愿意追求的最后一个选择是拥有一个仓库,然后我只应用于最新的供应商变更(从tarball中提取).我不愿意这样做,因为我觉得拥有供应商的日志信息(从https://github.com/magentomirror/magento-mirror中提取)对于整理新的更新并找出影响我的更改非常有帮助.

git magento git-submodules git-subtree

18
推荐指数
1
解决办法
1万
查看次数

将Git子模块转换为子树后合并错误

我有一个项目,我最初使用子模块的一些相关代码.事实证明,子模块并不适合这个项目(并且它们在实践中很难使用),因此我将每个子模块转换为子树(使用新git-subtree功能).

在我的工作存储库中,我已经成功删除了每个子模块,并将旧的子模块repo添加为子树.没问题.

当我转到另一个克隆并尝试从第一个克隆拉出时,我从合并步骤中收到以下错误:

error: The following untracked working tree files would be overwritten by merge:
        sub/.gitignore
        sub/Makefile
        sub/README
        sub/src/main.c
        ... and so on for all files in sub/
Aborting
Run Code Online (Sandbox Code Playgroud)

看来这是因为sub/首先在主存储库中从未真正存在过文件,并且当Git应用补丁进行更新时,.gitmodules它不会删除带有子模块文件的目录.当处理下一次提交时,Git尝试在其中创建新文件sub/,现在它们主存储库的一部分,所有这些文件都与仍然存在的文件冲突sub/.

我发现的解决方法是使用rm -rf sub之前git pull,这可以避免这个问题.

我的问题是,是否有任何命令行开关我可以使用git merge"覆盖工作目录中恰好存在的任何文件"?更好的方法是git merge查看现有文件的内容,如果内容与它要创建的文件完全相同,则禁止显示错误消息并继续.

更新:我已经创建了演示此问题的Git存储库,以准确显示我正在谈论的内容.重现:

$ git clone https://github.com/ghewgill/q14224966.git
$ cd q14224966
$ git submodule init
$ git submodule update
$ git merge origin/branch
Run Code Online (Sandbox Code Playgroud)

这应该导致错误消息

error: …
Run Code Online (Sandbox Code Playgroud)

git merge git-submodules git-subtree

18
推荐指数
1
解决办法
2528
查看次数

执行git子树拆分时请遵循重命名

我有许多子目录,我想把它们分成一个单独的仓库.为了使用单个命令提取它们,我将它们移动(重命名)到根目录内的单个子目录.

然后我跑: git subtree split -P my_new_subdir -b newbranch

如果我然后签出这个新分支并运行git log --follow someoldfile它只显示有关移动到临时子目录的日志条目.我想继续这些文件的完整历史记录.

有没有办法保存完整的历史记录,包括在进行子树分割时重命名?是否有另一种方法可以达到预期的效果?

我曾考虑在repo的克隆上使用filter-branch,但我知道这将非常慢.

git git-subtree

18
推荐指数
1
解决办法
1378
查看次数

git报告合并冲突没有变化,空行(使用git-subtree)

我正在测试使用git-subtree将库repo合并到一个更大的项目中.原则上似乎很棒.有时当我做一个"git subree pull"时,我会遇到这样的合并冲突:

<<<<<<< HEAD
=======
An inserted line from the lib repo
>>>>>>> 4d348903449ebb584ab224cb34c6038fbf6b352d
Run Code Online (Sandbox Code Playgroud)

这是在库仓库中进行的更改,合并到一个尚未在本地修改的文件中.或者另一个例子,我在本地项目仓库中添加了一行,但是在一个文件中,该文件是要合并的子树的一部分:

<<<<<<< HEAD
Another inserted line
=======
>>>>>>> 4d348903449ebb584ab224cb34c6038fbf6b352d
Run Code Online (Sandbox Code Playgroud)

为什么git会将这些报告为合并冲突,但该地区报告称冲突是空的?有什么方法可以预防吗?

这些很容易解决,但它搞砸了git子树的工作流程

git subtree git-subtree

16
推荐指数
1
解决办法
2241
查看次数

Git子树:仅使用子存储库而不是整个存储库

我有一个使用一些第三方库的项目.所以目录结构是这样的:

MY_COOL_PROJECT
   3rdParty
      LIB_1
      LIB_2
   Source
      MY_PROJECT   
Run Code Online (Sandbox Code Playgroud)

这些库位于不同的存储库中.所以,如果我想为第三方库使用git存储库,我可以这样做:

git subtree add --prefix 3rdParty/LIB_1 --squash http://My3rdPartyLibs.com/lib1.git master
Run Code Online (Sandbox Code Playgroud)

但是,在lib1.git存储库中,我只需要一个bin文件夹.它还包含文档,示例等文件夹.我怎样只能将我的存储库与lib1/bin文件夹"连接"而不是整个存储库?这甚至可能吗?

git git-subtree

16
推荐指数
1
解决办法
4992
查看次数

何时将大型Git存储库拆分为较小的存储库?

我正在努力从SVN迁移到Git.我已经习惯git-svn将历史记录放到一个git存储库中,我已经知道如何使用git-subtree将该存储库拆分为较小的存储库.这个问题不是关于如何进行迁移,而是关于何时拆分以及何时不进行拆分.

我想拆分大型存储库,因为某些目录是自包含的库,也与其他项目共享.以前svn checkout是在库上完成的,无需签出整个项目.在所有这些过程中,我发现可能有数十个目录在自己的存储库中是有意义的,因为它们是1)独立的,2)跨项目共享.

一旦你获得了一些git存储库,使用一个工具可以更容易地处理许多存储库似乎是明智的.一些例子是谷歌的repo,git submodules,git subtree,并创建自定义脚本(看来铬做到这一点).我已经探索了这些不同的方法,并了解如何使用它们.

所以问题是关于从颠覆过渡的方向.

我是否应该尝试坚持使用一个大型git存储库,只在绝对必要时才将其拆分成更小的部分,还是应该将其拆分为数十个或可能数百个较小的存储库? 哪个更容易使用?还有其他我错过的解决方案吗?如果使用多个存储库,我应该使用哪个工具?哪些因素会让某人偏爱另一种方法呢?

注意:需要在Windows,MacOS和Linux上签出源代码.

git version-control repository git-submodules git-subtree

16
推荐指数
1
解决办法
2070
查看次数