这是一个常见的情况,必须有一个明智的解决方案,但尽管阅读和大量的Git体操,我的大脑疼痛,我无法使这项工作......
我正在使用Wordpress,尽管这适合大多数网站开发方案。我想用git repo管理站点安装,并且还可以在单独的repos中管理各种WP插件,jQuery插件和其他代码位,这些插件可以很容易地从外部源拉出/推送。看起来很简单,直到你看到细节...
“子文件夹”标准 每个插件的文件夹不应绑定到其源代码的根文件夹。许多repos有多个嵌套文件夹,例如“my-repo-name / ...”,“dev /”,“test /”,“src /”,其中后者的内容是所需的东西。这对于保持引用URL清洁并最大限度地减少公众可用的垃圾非常重要。
“没有Proxys”标准 理想的解决方案不需要额外的中间分支或回购。将更改推送到插件的外部源应该很简单,不需要多次中间合并/推送。
“真实档案”标准 理想情况下,整个网站的外部回购实际上应该包含插件子项的文件(即没有“子模块”)。我可以被说服远离这一个......但
“发布”标准 它必须适用于rsync和/或git push'ing到实时服务器
Git子模块简单到足以进行更改和推/拉但子模块在“子文件夹”和“真实文件”标准上失败
Git读取树/子树合并解决“真实文件”问题,read-tree
实际上允许您引用分支的子文件夹但是当我这样做并尝试合并主服务器上的更改时在上游,Git没记住它来自一个子文件夹,并将master的整个结构合并到ext libs跟踪分支......所以FAIL就这个标准。
Apenwarrs子树扩展(here) 非常适合“真实文件”标准,并且相当简单的推/拉,直到您想要强制执行“子文件夹”规则。最好它似乎需要中间分支,您可以从远程跟踪分支中分离出所需的文件夹,然后将其作为子树添加到主分支。我没有太多运气将主人的变化合并/推送回源回购。我仍然认为这里可能存在......
与外部回购的符号链接 很好的解决方案,直到GIT停止遵循符号链接。现在它在“真实文件”和“发布”标准上失败了
嵌套回购
在某个地方,我看到了一个SO答案,如果你明确地git add
一个包含另一个repo并包含尾部斜杠的文件夹,git将不会对其进行子模块,而是跟踪单个文件。这似乎很有希望,但它在“子文件夹”标准上失败了。
我见过“稀疏结账”的提法 - 或许是涉及分支修剪的事情。我希望避免一个涉及shell脚本的解决方案,或者是如此复杂以至于每次都要重新学习它(不经常)我会对插件进行更改。它需要比为每个插件维护一个单独的repo并从主CMS安装中来回复制更容易。
当然有人有一个简单的功能方式来使这个常见的开发场景工作?在此先感谢您的帮助...
答案 0 :(得分:1)
显然你一直在考虑这个,我只是git的新手,但我的第一直觉是将.gitignore添加到plugins目录并让每个插件都拥有它自己的git repo。你可以为主题做同样的事情。所以我想这不仅仅是一个问题,而是一个答案 - 为什么这个简单的方法不起作用?
答案 1 :(得分:1)
我不知道这是否会完整地回答你的问题,甚至不能涵盖你的具体情况,但我认为无论如何我都会试一试。
我们有多个项目,其中许多项目互相引用,每个项目都在自己的Git存储库中。它们也包含在多个级别的文件夹中,例如:
Repos
- Utilities
- Util repo1
- Util repo2
- Common
- Lib repo1
- Lib repo2
- Projects
- Client1
- Git repo1
- Git repo2
- Client2 repo
- Client3
...
我们遇到了手动不得不推/拉/提交每个存储库的问题,这成了一场噩梦。
所以我们写了一个小实用程序,它能够一次对多个文件夹执行push,pull,commit,tag,remote diff和diff Git操作,以及同时构建多个VS解决方案文件。它还将检查子文件夹中的存储库。
我们已经使用了一段时间了,它对我们来说很好。您可以在此处查看:Gitter.7z
打开ReadMe.html文件以查看如何使用它。希望这会有所帮助,请告诉我。