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

Question

我正在尝试将所有内容添加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应该使用什么工具（例如），以及应该寻找什么输出？

注意：请不要仅回答如何匹配所有递归文件的问题，因为这将对我有一次帮助（此特定情况），而不是让我反复尝试新事物（任何情况）。

Answer 1

TL; DR

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

1. git add 有问题的文件。
2. 请执行以下任一操作：
   • 运行git lfs status并确保所涉及的文件出现在下方Git LFS objects to be committed，并确保其LFS值在括号中；要么
   • 运行git lfs ls-files并确保有问题的文件出现在此输出中。

?? 重要提示：运行后git lfs track，必须运行git add以刷新文件状态，然后再调用git lfs status或git lfs ls-files。否则，您将看到这些命令的不相关输出。

另外，为了进行记录，看起来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. 推送更改。包括添加/提交/推送.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确定的东西将是混帐LFS与否的一部分。
• 另一个陷阱：诸如Xcode之类的某些应用程序将以git add一种奇怪的方式归档，从而导致Git LFS不会考虑本应明确匹配的内容。解决方案是取消暂存文件，然后重新暂存它们。