我应该如何在300多个网站上使用git?

时间:2014-02-03 06:04:24

标签: git version-control github

目前,我负责改善一些不良的开发实践。我继承了一个生产服务器,其上运行着300多个网站,所有网站都有半相似的代码库。其中没有一个是完全相同的。所有站点都没有源代码管理。开发团队一直在使用复制目录和保存备份而不是工作并能够回滚更改的旧实践。这也使得很难找到谁在站点代码库上做了什么,特别是对于快速修复"。对我来说,合乎逻辑的结论是我们需要采用SCM。 Git是我的选择,因为它易于使用和启动和运行。它还有大量关于如何使用它并解决可能出现的问题的文档。唯一的问题是文档围绕单个站点使用而不是高容量生产环境。

我无法找到有关如何在这么多网站的生产环境中使用git的任何文档。我以前使用git的经验是在git上项目少于10个的环境中,每个项目都有自己的回购,这10个项目有些数千个网站都来自单个代码库。我的第一个想法是让每个站点都有自己的回购,因此它可以单独进行分支和开发,而不会影响任何其他站点。我和一些人讨论了这个话题,并且他们已经说过让所有300个网站都成为一个庞大的回购,然后只需要上下推动整个回购,这将是近300GB的数据被移动。我意识到Git会进行增量推送和拉动,因此每次推送和拉取数据不会超过300GB;但是,这可能是数千个需要搜索单个git状态的文件。这看起来有点矫枉过正,并且有可能出现很多问题,特别是我们有5-10人在同一个大型仓库下工作在多个网站上。

在这种情况下,哪个是最佳路线,1个单一的大型回购,还是数百个较小的回购?或者我还缺少另一种选择吗?

3 个答案:

答案 0 :(得分:3)

我认为将所有网站放入一个存储库并不是出于各种原因的最佳选择:

  1. 一个巨大的并不是最好的主意,正如所有其他答案所暗示的那样。
  2. 您可能不会在同一个发布周期中开发每个站点,但是使用一个repo时,很难查看不同版本,或者只回滚一个站点。
  3. 虽然您建议这些网站可能都有一个共同的代码库,但它不太可能在当前情况下对您有所帮助,因此将所有网站推入一个存储库在识别,隔离然后统一时没有任何好处可以共享的代码。
  4. 事实上,你可能正在接近所有网站的巨大重构任务,因为他们似乎使用几乎相同的代码,但我想知道是否真的如此,无论如何它都会帮助你。

    实际上,您可能会检测到例如您正在使用十个或二十个略有不同版本的数据库层或记录器。任何差异都无法删除,因为它对使用它的网站至关重要,并且与任何其他网站不兼容,因为使用的方法使用的签名与其他任何网站略有不同。它无法帮助您创建可由所有站点共享的源代码的单一真实版本,因为要使该代码在任何地方都可用,这将是一项巨大的工作。

    一步一步走。首先建立版本控制。每个站点一个repo允许您逐步创建所需的所有存储库。

    之后,您可以创建更多的存储库来创建一组包含真正可以共享的代码的库,或者替换那些与外部源完全不同的部分。无论是什么,都可以让您继续维护这些网站。

答案 1 :(得分:2)

我强烈建议您使用单个仓库,每个站点/网络应用程序一个。或者至少将300+分成较小的 密切 相关的网站集群分成一个大约10个左右的网站。或者可能由开发团队划分......但是没有一个庞大的回购!

虽然很可能一个可以拥有一个巨大的回购,但这实际上是不好的做法,取决于你的回购有多大,可能是一个坏主意。任何结构/文件变化变得越混乱的回购越大,简单重命名和合并之类的东西变得混乱无法处理。此外,如果Git需要更新数千个文件,那么在源历史记录中“回到过去”几乎是不可能的。

此外,出于备份和部署目的,您希望拥有较小的回购。我们有一个巨大的.NET解决方案仓库,里面有超过30个不同的项目,只需要半个小时来克隆它。这不怎么样。我们将其删除并从中删除任何“非源代码”内容(pdf,图像,二进制文件)并删除应该自己的项目。它更好,更快,通过历史航行是一件轻而易举的事。您还可以使用Amazon S3等云存储来处理静态的非源代码文件。

我们正在将nuget用于依赖项和外部库。不确定你正在使用什么框架/语言,但有很多非.NET工具可以帮助你管理这样的东西。 希望这会有所帮助。

PS:虽然使用Github,但使用更少的回购更便宜......也许最好寻找其他仅由开发人员收费的git主机... Bitbucket浮现在脑海中......

答案 2 :(得分:0)

你说你的“网站”非常相似,可能来自相同的代码库,然后很可能会有很多相同的文件(或内容差别很小的文件)。

请记住,git以其存储数据的方式非常高效,并且它具有delta压缩算法,该算法经过优化,只能在repo中存储类似的块一次。考虑到这一点,您应该尝试将所有这些站点放入单个git存储库并使用git gc进行优化 - 您可能会惊讶地发现git对象存储的实际大小可能比您的容易10倍期望的。