git - 带有 fork 的 Git LFS 的工作流程是什么？

Question

我已经将 Git LFS 引入了我在 bitbucket.org 上的存储库之一。 fork 此存储库的用户无法推送到他们的 fork ，因为那里没有 LFS 文件的空间。我的理解也是，当您在那里 fork 存储库时，不会复制 LFS 文件。

将 Git LFS 与 Bitbucket 一起使用是否意味着不可能或至少无法使用 fork ？或者是否有一个特殊的 Git 工作流程/配置可以在这里提供帮助？

请注意，就我而言，我使用 fork 主要是作为一种在上游持续工作的方式，我的团队的其他成员还没有准备好看到它。例如，我会将我未完成的工作推送到那里，以便我可以在不同的物理位置恢复。完成后，我将我的作品发布到 origin给其他队员看。

Answer 1

这是一个已知问题，请参阅 current limitations for Git LFS with Bitbucket .我也希望 Bitbucket(和 Github!)能够改进这一点。
结果:

LFS 文件必须在 fork 和上游 repo 之间手动同步

Fork 也将使用大量的大文件存储空间，而不仅仅是上游(有一个免费的存储配额 - 但在用完之后你将不得不为每个 fork 付费，哎哟!)

要将 LFS 文件从 fork 复制回上游，您需要对上游存储库的写访问权限，或者上游所有者必须自己完成

如何同步 LFS 文件:

第一次克隆 fork 存储库 - 它尚未复制任何 LFS 文件，因此您必须在没有 LFS 文件的情况下克隆它(否则克隆将失败)

export GIT_LFS_SKIP_SMUDGE=y
git clone <address of your fork>

同步上游 -> fork(将 LFS 文件复制到你的 fork) - 最初和每次你 git fetch 上游

git lfs fetch --all <upstream>
git lfs push --all <fork>

同步 fork -> 上游(仅当前分支) - 每次在您的 PR merge 后

git lfs fetch <fork>
git lfs push <upstream>

如果有比这更好的工作流程，请告诉我。这是 Bitbucket LFS 处理的严重限制。