我有一个已经启用了Git LFS的现有Git存储库。我已经有了使用LFS的*.foo文件的存储库，这在.gitattributes文件中很明显。
我有一个分支add-bar，在该分支上，我还决定对*.bar文件也使用Git LFS。 （我尚未向存储库中添加任何*.bar文件；我的问题不是关于迁移现有内容。）在我的add-bar分支中，我将这样做：
git lfs track "*.bar"
我相信这将再次更新我的.gitattributes文件。然后，我将添加我的.bar文件。
git add example.bar
git commit -m "Added my first bar."
git push -u origin add-bar
我不确定重新合并到master的确切方式。
git checkout master
git merge add-bar
git push
add-bar分支的.gitattributes已更新，以反映LFS处理*.bar文件，但.gitattributes中的master没有更新。合并会正确发生吗？即使*.bar中的.gitattributes在合并之前不了解LFS，LFS仍可正确用于master文件吗？即使git push文件在被LFS识别为受控制文件之前已合并，*.bar也会正确发生吗？
我甚至可能根本没有问正确的问题，或者没有以正确的方式问他们。当我与Git LFS一起工作时，这可能会变得很明显-也许我只需要再次查看它的机制。但是希望这个问题和答案对其他人也有帮助。
总而言之，如果不同的分支具有不同的.gitattributes设置以及LFS接管的时间，我不确定如何与Git LFS合并。
要在合并操作后检查git-lfs是否正在跟踪文件，请运行以下命令：
git lfs track
它应该返回此
Listing tracked patterns
*.foo (.gitattributes)
*.bar (.gitattributes)
Listing excluded patterns
第一次为现有存储库设置git-lfs时，您将提交.gitattributes文件。当执行合并操作时，如果没有冲突，则新的.gitattributes文件应包含要从两个分支中跟踪的模式。
但这不是问题。问题是当我开始跟踪分支中的文件类型，更新分支
.gitattributes，并在分支中添加新类型的文件；和然后将该分支合并到master中，而master尚未跟踪这些分支文件，并且尚未在其文件中反映该新文件类型.gitattributes。例如，Git LFS何时接管？如果是新文件类型在合并时不在
.gitattributes中（即在目标分支中）时间，新文件类型将存储为文字字节，而不是指针，因为.gitattributes仅在新文件具有已存储？
执行合并操作时，不涉及Git LFS。 git在合并操作期间，将指针文件和.gitattributes视为普通文件。
如果要在master分支中使用LFS文件（在合并操作之后，则需要执行检出操作。
git lfs checkout
或仅签出某些LFS文件的方法
git lfs checkout path/to/file1 path/to/file2
关于git lfs checkout为什么需要man-page的更多信息：
DESCRIPTION
[尝试确保工作副本包含Git LFS的文件内容当前对象的对象（如果对象数据可用）。才不是下载任何内容，请参阅git-lfs-fetch（1）。
[Checkout扫描当前ref以查找所有LFS对象。必需，然后在工作副本中缺少文件或包含具有相同SHA（真实文件）的占位符指针内容如果我们在本地商店中拥有内容，则将内容写入。改性文件永远不会被覆盖。