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

TL; DR

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

git add有问题的文件。
执行以下一项操作：
- 运行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/**"似乎是递归匹配的正确方法。

设置和测试方法：

git lfs track "*.lfs"。这将生成.gitattributes。放开它。
在根目录Test.lfs中创建一个文件。放开它。

测试：

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

添加git add Test.lfs。

测试：

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

提交更改。

测试：

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不应该考虑的明显匹配项。解决方案是先取消暂存文件，然后重新暂存它们。

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

1 个答案: