如何判断文件是否能够正确上传到Git LFS？

Question

如何判断文件是否能够正确上传到Git LFS？

95

我正在尝试将MyProject/Frameworks/下的所有内容添加到git-lfs（大文件存储）。我不确定匹配Frameworks文件夹下所有文件和文件夹的正确格式。这个答案说正确格式为git lfs track "MyProject/Frameworks/**"，但Atlassian的帮助文档说我应该使用git lfs track "MyProject/Frameworks/"。我尝试了两种方法，它们都没有使用git lfs进行存储。它尝试直接上传文件。

当然，我想知道正确的格式，但更重要的是，在我尝试将更改推送到github之前，我想验证匹配和文件是否确实正常工作。这将使我可以迭代并尝试新的东西。

我看到两个相关的命令可能有用：git lfs status和git lfs ls-files。不清楚应该使用哪个以及应该查看什么输出。例如，当我运行git lfs status时，它显示了大量文件在Git LFS objects to be committed下，让我认为它们将被添加到Git LFS中。但是，在尝试推送到GitHub.com之后，我意识到这显然不是这种情况。如果有帮助的话，这些文件的输出始终在每个文件名后面加上类似于(Git: edee1ad)的内容。

当我尝试使用git lfs ls-files时，我不确定是否需要在git add文件之后、提交文件之后或推送文件之后运行它。大多数时候它只会显示空白输出。

基本上问题是：如果我正确配置了git lfs，那么我应该使用哪个工具（例如git lfs status），并且在尝试提交/推送之前应该查看什么输出？

注意: 请不要仅回答如何匹配所有递归文件，因为那只有在特定情况下才有用，而不允许我迭代并尝试新的方法（任何情况下都有用）。

- Senseful

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Senseful · Accepted Answer

TL;DR

To verify that git LFS is working correctly, add the file(s) and run either "git lfs status" or "git lfs ls-files" to ensure the files appear with the LFS value in parenthesis. After running "git lfs track", refresh the file state by running "git add" before calling "git lfs status" or "git lfs ls-files". Use "git lfs track 'MyProject/Frameworks/**'" for recursive matching. To test, generate .gitattributes with "git lfs track '*.lfs'", create a file Test.lfs in the root directory, and run "git lfs status" to ensure filenames are outputted.

$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:


Git LFS objects to be committed:


Git LFS objects not staged for commit:


$

git lfs ls-files: 没有输出

$ git lfs ls-files
$

执行git add Test.lfs命令。

测试:

git lfs status: 现在会列出带有LFS后缀的Test.lfs。

$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:


Git LFS objects to be committed:

        Test.lfs (LFS: 2ab9f1e)

Git LFS objects not staged for commit:


$

git lfs ls-files 命令：现在会列出 Test.lfs。

$ git lfs ls-files
2ab9f1e447 * Test.lfs
$

提交更改。

测试:

git lfs status: Test.lfs将会被移动到“待推送”部分。它将有一个带有一堆数字/字母后缀的后缀。

$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:

        Test.lfs (2ab9f1e44720efb7a26553e06b667a270320efb3e906553b3f9e0702538a2b3f)

Git LFS objects to be committed:


Git LFS objects not staged for commit:


$

git lfs ls-files：仍将列出Test.lfs。

$ git lfs ls-files
2ab9f1e447 * Test.lfs
$

推送更改，包括添加/提交/推送 .gitattributes。

测试:

git lfs status: 不再输出文件名

$ git lfs status
On branch master
Git LFS objects to be pushed to origin/master:


Git LFS objects to be committed:


Git LFS objects not staged for commit:


$

git lfs ls-files: 继续输出已跟踪的文件

$ git lfs ls-files
2ab9f1e447 * Test.lfs
$

结论:

Git LFS objects not staged for commit部分似乎是误导性的，因为它从未显示任何文件，即使那些应该由LFS跟踪。
如果您尝试使用非git-lfs跟踪的文件进行上一个实验，您也会注意到它错误地出现在Git LFS objects to be committed下。它不是Git LFS对象。但您可以通过观察其结尾方式来确定它实际上不是Git LFS对象。如果以 (Git: 111111111)结尾，则不会提交到LFS中。
为避免上述混淆，建议您使用git lfs ls-files而不是git lfs status来确定某个内容是否将成为git-lfs的一部分。
另一个要注意的问题是，某些应用程序（如Xcode）会以奇怪的方式 git add 文件，导致本应清晰匹配的内容不被视为Git LFS的一部分。解决方案是取消暂存文件，然后重新暂存它们。