1

我的代码每天由多人（多台机器）多次编译。每次有人完成编译时，我希望每个编译都自动上传到我们的 Github 帐户。基本上，这些编译后的 zip 通过闪存驱动器、电子邮件或保管箱（基于多种条件的任意数量的方式）发送到实际硬件。由于 zip 始终命名相同，因此有时旧版本会在设备上被删除，有时存储在 /old 目录中。我想停止丢失旧版本并保留按时间顺序存储的每个版本的中央存储库。Github 似乎是一个完美的地方。

我当然可以要求每个用户将他们创建的完成的 zip 上传到一个中心位置，但如果可能的话，我希望它是一个自动过程。那么——Github 是否提供这样的功能？

4

3 回答 3

4

Github 似乎是一个完美的地方。

并非如此，因为将大型二进制文件放入分布式存储库（即，整个克隆的存储库）不是一个好主意。

要获得特定版本的二进制文件，您必须先从 GitHub 克隆您的“工件”存储库，然后才能选择正确的进行部署。
随着多次交付，该回购将变得越来越大，从而使克隆更长。
但是，如果您只有一个地方可以部署，那么 git fetch 确实只会获得新的工件（增量更新）。

但：

  • GitHub 并没有提供无限的空间（同样，随着所有交付，该 repo 会迅速增长）
  • 清理存储库（即删除您可能不需要的旧版本的二进制文件）很难。

因此，再次使用 GitHub 或任何其他 DVCS（分布式 VCS）进行交付似乎还不够。

如果您可以设置像Nexus这样的公共工件存储库，那么您将能够交付任意数量的二进制文件，并且您将能够轻松地清理它们（删除它们）。

于 2012-07-01T22:19:52.737 回答
3

Github 具有附加到存储库的文件的概念（但实际上不在存储库中 - 它们存储在 s3 上），并且有一个用于将文件上传到其中的api。

您可以将该 API 称为构建过程的一部分。

如果您有一个持续集成服务器在每次提交后构建您的代码，您应该能够将其存储在某个地方，但如果您希望将它们存储在 GitHub 上（而不是 CI服务器硬盘）

于 2012-07-01T22:22:25.433 回答
2

虽然 github 非常适合在源代码上进行协作，但它不适用于管理构建及其工件。您最终可能会想看看像Cloudbees这样的公司，它们提供托管构建和集成环境，它们的目标正是源代码管理之外的工作流部分。但这些主要针对 Java 开发，这可能符合您的需求，也可能不符合您的需求。

除此之外，如果您真的只想让很多人可以访问您的构建中的大量带有时间戳的 zip 文件，那么一个好的老式 FTP 服务器可能不足以满足您的需求吗？

于 2012-07-02T18:13:35.217 回答