git - 如何判断文件是否会正确上传到 git lfs？

Question

我正在尝试将 MyProject/Frameworks/ 下的所有内容添加到 git-lfs (大文件存储)。我是 not sure在 Frameworks 文件夹下递归匹配所有文件和文件夹的正确格式是什么。 This answer表示正确的格式是 git lfs track "MyProject/Frameworks/**"，但是 Atlassian's help document说我应该使用 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)，我应该查看什么输出之前我尝试提交/推送？

注意:请不要仅回答如何匹配所有递归文件的问题，因为这只会帮助我一次(这种特定情况)，而不是让我迭代和尝试新事物(任何情况)。

Answer 1

长话短说

如果一切设置正确，您可以通过以下方式验证 git LFS 是否正常工作:

1. git add 有问题的文件。
2. 执行以下操作之一:
   • 运行 git lfs status 并确保相关文件出现在 Git LFS objects to be committed 下，并且它们具有 LFS括号中的值；或
   • 运行 git lfs ls-files 并确保相关文件出现在此输出中。

⚠️ Important: After running git lfs track, you must run git add to refresh the state of files before calling git lfs status or git lfs ls-files. Otherwise you'll see irrelevant output from those commands.

此外，作为记录，看起来 git lfs track "MyProject/Frameworks/**" 是递归匹配的正确方法。

---

设置和测试方法:

1. git lfs track "*.lfs"。这会生成 .gitattributes。让它不被暂存。
2. 在根目录下创建文件Test.lfs。让它不被暂存。

3. 测试:

   • 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
     $
     

4. 添加git add Test.lfs。

5. 测试:

   • git lfs status:Test.lfs 现在将以 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
     $
     

6. 提交更改。

7. 测试:

   • 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
     $
     

8. push 变化。包括添加/提交/推送 .gitattributes。

9. 测试:

   • 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 不考虑本应明确匹配的内容。解决方案是取消暂存文件，然后重新暂存它们。