使用git-buildpackage时，有两种方式获取上游源：

我的团队正在研究打包 Oracle Java。我们在 git 中开发我们的包并希望使用 gbp。显然，选项(1)是不可能的，因为来源不可用。但是选项(2)也不可行，因为这意味着将巨大的(200MB)档案导入 git.

由于 Debian\\ 的政策是针对专有软件的，因此您在此找不到太多关于此用例的文档。不过，还是有办法的。

dpkg-buildpackage 也是不够的，因为 get-orig-sources 已被弃用。现在您应该使用 uscan 和 debian/watch 或 git-buildpackage.

是什么让你觉得有？
将"巨大"压缩包导入 git 存储库时，您预计会出现哪些问题？
它们与 gbp 有关吗？或者它只是 git 处理大型二进制 blob 的方式(这实际上是完全不同的事情)。
如果您真的关心大型存储库大小，您可能想要签出 git-lfs 或类似内容。

由于 Debian 的政策是针对专有软件的，因此您在此找不到太多关于此用例的文档。

哪个用例？
拥有庞大的发行版 tarball 并不是专有软件所独有的。
(思考游戏……有数以百万计的数据附带的 FLOSS 游戏)。

所以你的选择是：
- 要么包括大型上游 tarball
- 或者重新打包它们以丢弃您不需要的东西(例如，W32、W64 和 BeOS 的预编译二进制文件在 Debian 包的上下文中通常是无用的，但会极大地增加包的大小)。获取上游 tarball (uscan) 的标准工具包括在导入新的上游版本时自动删除文件的机制。

get-orig-source 已弃用

那又怎样？您引用的文章明确指出它"在 debian/rules 文件中的存在绝对没问题"。
此外， git-orig-source 与 uscan 的问题与您描述的问题正交。
两者都是从远程位置获取源代码以开始打包新版本的方法。
在构建过程中也不能用于获取其他缺失的上游源(您可能会感到困惑，因为 get-orig-source 是 Makefile 目标。但这个目标实际上从未被调用，除非由想要获取的人手动调用来源)。

dpkg-buildpackage 也不够

为什么不呢？
如果你在 dpkg-buildpackage 可以找到的地方有 orig-tarball，你当然可以使用它。

gbp 是一个非常好的集成工作流工具，可将 Debian 打包(/debian 中的所有内容)和上游快照保存在单个存储库中。

这可能不一定是您想要的工作流程(例如，因为您明确不希望在打包存储库中包含上游源)。

在这种情况下，gbp 可能不适合您。

幸运的是，绝对没有任何东西迫使您使用这个工具。随意使用 git-dpm、dpkg-buildpackage 或在没有任何帮助的情况下手动滚动您自己的包。