11

我们最近从 subversion 转到 git，然后转到 Github，用于几个开源项目。Github 很好，因为它提供了很多功能。我特别喜欢的一件事是将标签下载为文件的zip能力.tar.gz。

不幸的是，Github 最近停止了下载。由于能够下载标签，这应该不是问题。然而，过去我们没有将Makefile,configure脚本或任何其他 autoconf 生成的文件放入 repo，因为当人们合并时它们会产生很多冲突。

处理这个问题的正确方法是什么？

  • 我应该将 autoconf 和 automake 生成的文件放在 repo 中，以便人们可以直接下载标签吗？
  • 还是应该有一个bootstrap.sh文件并告诉人们运行它？
  • 还是我应该做一个make dist并将其放入回购中？

谢谢

4

3 回答 3

19

make dist通过 GitHub Releases发布输出

您的第一个选项——将 Autoconf 和 A​​utomake 生成的文件放入存储库——不是一个好主意。将生成的文件存储在源代码管理中几乎没有什么好处。在这种情况下，它会通过大量不必要的和潜在的冲突提交污染您的历史记录，特别是如果不是所有贡献者都使用相同版本的 Autotools。您的第三个选项——检查输出make dist——是一个坏主意，原因与第一个选项完全相同。

您的第二个选项——添加一个调用 Autoconf 和 A​​utomake 来生成脚本的“引导”configure脚本——也是一个坏主意。这违背了 Autotools 的全部目的，即使您的源代码可跨系统移植——包括那些 Autotools 不可用的系统！（考虑如果有人想在他们没有 root 访问权限且未安装 GNU 构建系统的机器上构建和安装您的软件会发生什么。引导脚本不会帮助他们，因为他们会首先需要在本地安装 Autotools 及其所有依赖项。）

使用 Autotools 发布代码的正确方法是生成一个 tarball make dist（或者更好的是make distcheck，因为这也将运行测试并进行其他完整性检查），然后将此 tarball 发布到源存储库以外的其他地方。

您从 2013 年 4 月开始的原始问题指出 GitHub 已停止下载页面。然而，在 2013 年 7 月，GitHub 添加了“发布”功能，不仅可以预先打包您的源标签，还允许您将任意文件附加到每个发布。因此，在 GitHub 上，发布页面是您应该发布make disttarball的地方（最好还有它们的分离 GnuPG 签名）。

基本步骤

  1. 当您准备好发布时，标记它并将标记推送到 GitHub： $ git tag 1.0 # Also use -s if desired $ git push --tags
  2. 使用您的 Makefile 生成一个 tarball： $ make dist # Alternatively, 'make distcheck'
  3. 访问您项目的 GitHub 页面并点击“发布”链接： 显示发布链接位置的 GitHub 项目的屏幕截图
  4. 您将被带到您的项目的发布页面。第一次访问时，您将看到的只是标签列表和从源代码树自动生成的 tarball： GitHub 发布页面 按“Draft a new release”按钮。
  5. 然后，您将看到一个表单，您应该在其中填写与发布关联的 Git 标记以及可选的标题和描述。在此下方还有一个文件选择器，标记为“通过将二进制文件拖放到此处或选择它们来附加二进制文件”。使用它来上传您在步骤 2 中创建的 tarball（也可能是它的分离 GnuPG 签名）。 起草 GitHub 版本 完成后，按“发布版本”按钮。
  6. 您项目的 Releases 页面现在将显示该版本，包括附加文件的显着下载链接： 完成 GitHub 发布页面

如果您不想使用 GitHub Releases，那么正如之前的回答中所指出的，您应该将 tarball 上传到其他地方，例如您自己的网站或 FTP 站点。从您的项目中添加指向此存储库的链接，README.md以便用户可以找到它。

于 2016-12-28T10:41:55.680 回答
4

第二个更好：您希望您的存储库的任何用户尽快启动并运行，重新生成他/她需要的内容以构建您的程序。

由于 Git 在很大程度上是文本的版本控制（与 Nexus 等工件存储库相反），因此提供一种生成最终二进制文件的方法是可行的方法。

于 2013-04-01T14:48:32.007 回答
-1

当您剪切一个版本时，将结果上传make distcheck到您项目的下载页面：它是一个构建 tarball 并验证它是否安装、卸载、通过测试和其他健全性检查的 makefile 目标。Github 走错路不是借口：在你的 repo 中创建这样的树：

/
/source
/source/configure.ac
/source/Makefile.am
/source/...
/releases
/releases/foo-0.1.tar.gz
/releases/...

对于开发人员，您不应该在源代码管理中生成文件。许多现代自动工具项目通过调用autoreconf -i.

于 2013-04-02T00:11:04.810 回答