Git 不移动到特定分支
Git not moving to a specific branch
我克隆了一个我正在处理的项目。然后我尝试使用 git checkout branch_name 移动到特定分支但没有任何反应，终端只是添加一个空行。一段时间后，终端处于相同状态。没有任何变化。
我使用 git lfs clone https_url_to_repo
克隆了它
我试过的：
- 再次克隆它
- 在我的 mac
中重新安装 git
没有任何效果。
Git version = 2.13.2 (installed using homebrew)
Git-lfs version = 1.5.5 (installed using homebrew)
注意：我可以转到其他分行，问题就在那个分行。
也许这个问题是因为我在移动到那个分支时互联网连接中断了。
总结：
这很可能是由于 Git-LFS 中的一个错误，Git-LFS 的更新版本中的修复（或至少是解决方法）。
有关错误的描述，请参阅 https://github.com/git-lfs/git-lfs/issues/1880 and https://github.com/git-lfs/git-lfs/pull/1932 和 fix/work-around。
不过这是我的胶囊摘要：
当您使用 Git-LFS 时，您的标准 Git 配置被修改为使用 Git 的 clean 和 smudge过滤进程。 涂抹过滤器 意味着 "dirty up" 一个文件，因为它来自版本控制系统，干净过滤器 是它的逻辑相反：它清理文件以存储在 VCS 中。要使用此类过滤器，您必须标记 .git/config 文件和 .gitattributes 文件； Git-LFS 自动为您做这个标记。
作为一个有点愚蠢的例子，有些人喜欢让每行以 CR-LF 结尾，而不是仅换行（仅 LF），但存储文件的版本控制版本以换行符结尾。 Git 可以直接执行此操作（使用行尾过滤器）但是如果出于某种原因你想自己编写一个程序来执行此操作，你可以使用涂抹过滤器将 LF-only 替换为 CR-LF，并使用干净的过滤器将 CR-LF 替换为 LF-only。然后，您的工作树文件将具有所需的 Windows 样式的行结尾，而您提交的文件将具有所需的 Linux 样式的行结尾。
更实际的是，有些人喜欢扩展关键字（例如 RCS 或 CVS 类 $Id$）。 Git 还包括一个内置的 ident 过滤器，专门为 $Id$ 执行此操作。扩展是在将文件提取到工作树时完成的（就像通过污迹过滤器一样），并在添加文件以进入新提交时被删除——放回 $Id$。1 如果您想处理更多关键字，例如 $Log$、2，您必须编写自己的过滤器。
Git-LFS 所做的是使用（滥用？）干净和污迹过滤器来替换 大型 具有特殊修饰的哈希 ID 的文件，这些哈希 ID 充当 "pointers" 到外部大文件存储。这样，Git 从不存储——甚至 看到，在某种意义上，根本不会存储大文件。它只看到并存储这些经过修饰的哈希。 Git-LFS 过滤器负责在结帐时用实际的大文件内容替换有趣的哈希，并在 [=17 处用有趣的哈希（新的或重新使用）替换大文件内容=]时间。
但是有一个技术故障：Git 使用 管道 来实现涂抹和清洁过滤器。 （这些管道最近变得很花哨；有关详细信息，请参阅 the Long Running Filter Process section of the gitattributes documentation.) The Git-LFS code and the Git code itself must be careful not to "constipate" the pipes ... and, well, it wasn't. (See my answer to live output from subprocess command。）
1具体来说，从 Git 的 index 到工作树。当文件从工作树复制到索引中时，干净的过滤器将应用于文件。由于提交的树 仅 从索引中找到的文件构建，并且索引版本始终为 "clean"，因此所有提交也始终是干净的。
2$Log$ 在 RCS 和 CVS 中所做的是扩展到文件的整个日志消息历史记录——本质上，所有触及文件的提交, 除了 RCS 和 CVS 是基于文件的而不是基于提交的——所以当你编辑文件本身时历史就在那里。之前实际使用过这些东西，我坚信这是一个 坏主意： 这种元数据只属于版本控制系统（像 Git 或 Mercurial , 应该 分布式 并且开发人员可以访问整个存储库）。尽管如此，还是有人喜欢这样，技术上可以做到Git。
我克隆了一个我正在处理的项目。然后我尝试使用 git checkout branch_name 移动到特定分支但没有任何反应，终端只是添加一个空行。一段时间后，终端处于相同状态。没有任何变化。
我使用 git lfs clone https_url_to_repo
我试过的：
- 再次克隆它
- 在我的 mac 中重新安装 git
没有任何效果。
Git version = 2.13.2 (installed using homebrew)
Git-lfs version = 1.5.5 (installed using homebrew)
注意：我可以转到其他分行，问题就在那个分行。 也许这个问题是因为我在移动到那个分支时互联网连接中断了。
总结：
这很可能是由于 Git-LFS 中的一个错误，Git-LFS 的更新版本中的修复（或至少是解决方法）。
有关错误的描述，请参阅 https://github.com/git-lfs/git-lfs/issues/1880 and https://github.com/git-lfs/git-lfs/pull/1932 和 fix/work-around。
不过这是我的胶囊摘要：
当您使用 Git-LFS 时，您的标准 Git 配置被修改为使用 Git 的 clean 和 smudge过滤进程。 涂抹过滤器 意味着 "dirty up" 一个文件，因为它来自版本控制系统，干净过滤器 是它的逻辑相反：它清理文件以存储在 VCS 中。要使用此类过滤器，您必须标记 .git/config 文件和 .gitattributes 文件； Git-LFS 自动为您做这个标记。
作为一个有点愚蠢的例子，有些人喜欢让每行以 CR-LF 结尾，而不是仅换行（仅 LF），但存储文件的版本控制版本以换行符结尾。 Git 可以直接执行此操作（使用行尾过滤器）但是如果出于某种原因你想自己编写一个程序来执行此操作，你可以使用涂抹过滤器将 LF-only 替换为 CR-LF，并使用干净的过滤器将 CR-LF 替换为 LF-only。然后，您的工作树文件将具有所需的 Windows 样式的行结尾，而您提交的文件将具有所需的 Linux 样式的行结尾。
更实际的是，有些人喜欢扩展关键字（例如 RCS 或 CVS 类 $Id$）。 Git 还包括一个内置的 ident 过滤器，专门为 $Id$ 执行此操作。扩展是在将文件提取到工作树时完成的（就像通过污迹过滤器一样），并在添加文件以进入新提交时被删除——放回 $Id$。1 如果您想处理更多关键字，例如 $Log$、2，您必须编写自己的过滤器。
Git-LFS 所做的是使用（滥用？）干净和污迹过滤器来替换 大型 具有特殊修饰的哈希 ID 的文件，这些哈希 ID 充当 "pointers" 到外部大文件存储。这样，Git 从不存储——甚至 看到，在某种意义上，根本不会存储大文件。它只看到并存储这些经过修饰的哈希。 Git-LFS 过滤器负责在结帐时用实际的大文件内容替换有趣的哈希，并在 [=17 处用有趣的哈希（新的或重新使用）替换大文件内容=]时间。
但是有一个技术故障：Git 使用 管道 来实现涂抹和清洁过滤器。 （这些管道最近变得很花哨；有关详细信息，请参阅 the Long Running Filter Process section of the gitattributes documentation.) The Git-LFS code and the Git code itself must be careful not to "constipate" the pipes ... and, well, it wasn't. (See my answer to live output from subprocess command。）
1具体来说，从 Git 的 index 到工作树。当文件从工作树复制到索引中时，干净的过滤器将应用于文件。由于提交的树 仅 从索引中找到的文件构建，并且索引版本始终为 "clean"，因此所有提交也始终是干净的。
2$Log$ 在 RCS 和 CVS 中所做的是扩展到文件的整个日志消息历史记录——本质上，所有触及文件的提交, 除了 RCS 和 CVS 是基于文件的而不是基于提交的——所以当你编辑文件本身时历史就在那里。之前实际使用过这些东西，我坚信这是一个 坏主意： 这种元数据只属于版本控制系统（像 Git 或 Mercurial , 应该 分布式 并且开发人员可以访问整个存储库）。尽管如此，还是有人喜欢这样，技术上可以做到Git。