Git，sub-repos&外部库用于Web开发 - 最佳策略一劳永逸？ [英] Git, sub-repos & external libs for web development - best strategy once and for all?

问题描述

这是一个常见的情况，必须有一个明智的解决方案，但尽管页面阅读和丰富的Git体操，我的大脑疼痛，我无法使这项工作...

我使用Wordpress，虽然这将适合大多数网站开发的场景。我想用git repo管理网站安装，并且管理各种WP插件，jQuery插件和其他代码位在单独的repos，可以很容易地从他们的外部来源拉/推。看起来很简单，直到你看看细节...

标准

子文件夹条件
每个插件的文件夹不应绑定到其源代码的根文件夹。许多repos有多个嵌套的文件夹，如my-repo-name / ...，dev /，test /，src /，其中后者的内容是必需的。

无Proxys条件
理想的解决方案不需要额外的中间分支或回购。对插件的外部源进行更改应该很简单，不需要多个中间合并/推送。

真实文件标准
理想情况下，整个网站的外部库应该包含插件子文件即没有子模块）。

发布条件
它必须与rsync和/或者git push到现场服务器

我看过这五个解决方案

Git子模块足够简单，可以进行更改和推/拉，但子模块在子文件夹和实际文件条件下失败

树/子树合并解决Real Files问题， read-tree 实际上允许您引用分支的子文件夹，但是当我这样做并尝试合并更改主回来上游，Git未能记住它来自一个子文件夹，并将主机的整个结构合并到了ext libs跟踪分支...因此失败了这个标准。

strong> Apenwarrs子树扩展（此处）
非常适合Real文件标准和相当简单的推/拉，直到你想强制执行子文件夹规则。最好它似乎需要中间分支，你从远程跟踪分支拆分出你想要的文件夹，然后将它作为一个子树添加到你的主分支。我没有太多运气将主机上的更改合并/推送回源代码库。我仍然认为这里可能有可能...

与外部代理的符号链接
伟大的解决方案，直到GIT停止下面的符号链接。现在在真实文件和发布条件失败了

嵌套回复
在某处我看到一个SO答案，显式地 git add 一个包含另一个repo并包含尾部斜杠的文件夹，git将不会子模块，而是跟踪单个文件。

接下来是什么？

我见过引用稀疏检出 - 或者可能是涉及分支修剪的东西。我希望避免一个解决方案涉及shell脚本或是如此复杂，它要求我重新学习它每次（很少）我改变一个插件。它需要比为每个插件维护一个单独的repo和复制从主CMS安装更容易。

当然有人有一个简单的功能的方法，使这个常见的dev场景工作？先感谢您的帮助...

解决方案

我不知道这将完全回答你的问题，覆盖你的具体情况，但我认为我会在任何情况下给它一个。

我们有多个项目，其中很多都相互引用，每个项目都在自己的Git仓库中。它们还包含在多个文件夹级别，例如：

  Repos 
  - 实用程序
  -  Util repo1 
  -  Util repo2 
  -  Common 
  -  Lib repo1 
  -  Lib repo2 
  - 项目
  -  Client1 
  -  Git repo1 
  -  Git repo2 
  -  Client2 repo 
  -  Client3 
 ... 
  

我们有一个问题，手动必须推/拉/提交每个存储库，这成为一个噩梦。

所以我们写了一个实用程序， do push，pull，commit，tag，remote diff和diff Git操作一次在多个文件夹，以及同时构建多个VS解决方案文件。它还会检入子文件夹中的存储库。

我们已经使用了一段时间，它对我们工作很好。您可以从这里查看： Gitter.7z

打开ReadMe.html文件以查看如何使用它。希望这有帮助，让我知道。

This is such a common scenario that there must be a sensible solution, yet despite pages of reading and copious Git gymnastics, my brain aches and I'm unable to make this work...

I'm working with Wordpress, though this will fit most website dev scenario's. I want to manage the site install with a git repo and also manage various WP plugins, jQuery plugins and other code bits in separate repos which can easily be pulled/pushed from their external sources. Seems simple enough until you look at the details...

The criteria

"Subfolders" criterion The folder for each plugin should not be bound to the root folder of its source repo. Many repos have multiple nested folders such as "my-repo-name/...", "dev/", "test/", "src/" where the contents of the later is the thing required. This is important to keep the referencing URLs clean and to minimise publicly available rubbish.

"No Proxys" criterion The ideal solution would not require additional intermediary branches or repos. Pushing changes to a plugin's external source should be simple and not require multiple intermediary merges/pushes.

"Real Files" criterion Ideally the outer repo for the whole website should actually contain the files of the plugins' subrepos (ie no "submodules"). I could be persuaded away from this one though...

"Publishing" criterion It must play well with rsync and/or git push'ing to the live server

I've looked at these five solutions

Git Submodules Simple enough for making changes and pushing/pulling but submodules fail on the "Subfolders" and "Real File" criteria

Git read-tree/subtree merge Solves the "Real Files" problem and read-tree actually lets you reference a branch's subfolder but when I did so and tried to merge changes on master back upstream, Git failed to remember that it came from a subfolder and merged master's whole structure into the ext libs tracking branch...so FAIL on this criterion.

Apenwarrs subtree extension (here) Great for the "Real Files" criterion and fairly simple to push/pull until you want to enforce the "Subfolders" rule. At best it then seems to require intermediary branches where you split out the folder you want from the remote tracking branch and then add this as a subtree to your master branch. I didn't have much luck merging/pushing changes on master back to the source repo. I still think there might be possibility here...

Symbolic links with external repo Great solution until GIT stopped following symlinks. Now it fails on "Real Files" and "Publishing" criteria

Nested repos Somewhere I saw an SO answer where if you explicitly git add a folder which contains another repo and include the trailing slash, git will NOT submodule it but instead track the individual files. This seemed promising but it fails on the "Subfolders" criterion.

What next?

I've seen references to "sparse checkout" - or perhaps a something involving branch pruning. I'm hoping to avoid a solution that involves shell scripts or is so complex that it requires me to re-learn it every time (infrequent) I make a change to a plugin. It needs to be easier than maintaining a separate repo for each plugin and copying back and forth from the main CMS installation.

Surely someone has a simple functional way to make this common dev scenario work?? Thanks in advance for the help...

解决方案

I don't know if this will answer your question in full, or even cover your specific scenario, but I thought I'd give it a go in any case.

We have multiple projects, many of which reference each other, each in their own Git repository. They are also contained in multiple levels of folders, for example:

Repos
    - Utilities
        - Util repo1
        - Util repo2
    - Common
        - Lib repo1
        - Lib repo2
    - Projects
        - Client1
            - Git repo1
            - Git repo2
        - Client2 repo
        - Client3
        ...

We had an issue with manually having to push / pull / commit each repository, which became a nightmare.

So we wrote a little utility program that is able to do push, pull, commit, tag, remote diff and diff Git operations on multiple folders at a time, as well as build multiple VS solution files at the same time. It will also check in sub folders for repositories.

We have been using it for some time now, and it works fine for us. You can check it out from here: Gitter.7z

Open the ReadMe.html file to see how to use it. Hope this helps out, let me know.

这篇关于Git，sub-repos&外部库用于Web开发 - 最佳策略一劳永逸？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！