我克隆了一个我正在研究的项目。然后我尝试使用git checkout branch_name移动到特定的分支，但没有任何反应，终端只添加一个空行。一段时间后终端处于相同的状态。什么都没有改变。
我使用git lfs clone https_url_to_repo
我尝试了什么：
没有任何效果。
Git version = 2.13.2 (installed using homebrew)
Git-lfs version = 1.5.5 (installed using homebrew)
注意：我可以转移到其他分支机构，问题就在于那个分支机构。 也许问题是由于我的互联网连接在转移到该分支时出现中断而引起的。
答案 0 :(得分：1)
<强>要点：
这很可能是由于Git-LFS中的一个错误，修复（或至少是解决方法）是Git-LFS的稍新版本。
有关错误和修复/解决方法的说明，请参阅https://github.com/git-lfs/git-lfs/issues/1880和https://github.com/git-lfs/git-lfs/pull/1932。
这是我的胶囊摘要：
当您使用Git-LFS时，您的标准Git配置会被修改为使用Git的 clean 和 smudge 过滤进程。 涂抹过滤器意味着＆＃34;脏污＆＃34;一个来自版本控制系统的文件， clean filter 是逻辑相反的：它清理文件以便在VCS中存储。要使用此类过滤器，您必须标记.git/config文件和.gitattributes文件; Git-LFS会自动为您进行标记。
作为一个有点愚蠢的例子，有些人喜欢让每一行以CR-LF结束而不仅仅是换行（仅限LF），而是以换行符结尾存储版本控制版本的文件。 Git可以直接执行此操作（使用行尾过滤器）但是如果由于某种原因你想编写一个程序来自己完成，你可以使用涂抹过滤器来替换仅使用CR-LF的LF，并使用干净过滤器仅用LF替换CR-LF。然后，您的工作树文件将具有所需的Windows样式行结尾，而您提交的文件将具有所需的Linux样式行结尾。
更实际的是，有些人喜欢扩展关键字（例如RCS-或类似CVS $Id$）。 Git还包含一个内置的ident过滤器，专门针对$Id$执行此操作。在将文件提取到工作树时（就像通过涂抹过滤器一样）完成扩展，并且在添加文件以进入新提交时将其删除 - 放回到$Id$。 1 如果您想处理更多关键字，例如$Log$， 2 ，则必须编写自己的过滤器。
Git-LFS做的是使用（滥用？）干净和污迹过滤器来替换带有特殊装饰散列ID的大型文件，这些散列ID充当＆＃34;指针＆＃34;到外部大文件存储。这样， Git 从不存储 - 甚至看到，在某种意义上 - 根本就是大文件。它只看到并存储了这些装饰的哈希。 Git-LFS过滤器负责在结账时用实际的大文件内容替换有趣的哈希，并在git add时用有趣的哈希（新的或适当时重新使用）替换大文件内容。
但是存在技术故障：Git使用管道来实现涂抹和清洁过滤器。 （这些管道最近变得相当花哨;参见the Long Running Filter Process section of the gitattributes documentation。）Git-LFS代码和Git代码本身必须小心，不要随意使用＃34;管道......而且，它不是。 （有关详细信息，请参阅my answer至live output from subprocess command。）
1 具体来说，当从Git的索引复制文件时，涂抹过滤器（以及ident和任何行尾黑客）会应用于文件到工作树。将清除过滤器从工作树复制到索引时应用于文件。由于已提交的树只是从索引中找到的文件 构建的，并且索引版本始终是＆＃34; clean＆＃34;，所有提交也始终是干净的。
2 RCS和CVS中$Log$的作用是扩展到文件的整个日志消息历史记录 - 本质上是所有触及文件的提交，除了RCS和CVS是基于文件而不是基于提交的 - 因此当您编辑文件本身时，历史记录就在那里。之前实际使用过这些东西后，我坚信这是一个错误的想法：这种元数据只属于版本控制系统（与Git或Mercurial一样，应该分发，开发人员可以访问整个存储库）。尽管如此，有些人喜欢这样，技术上可以在Git中完成。