Git 没有移动到特定的分支

Question

我克隆了一个我正在处理的项目。然后我尝试使用 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)

注:我可以搬到其他分支机构，问题就在那个分支机构。
问题可能是因为我在移动到那个分支时互联网连接中断了。

Answer 1

摘要:

这很可能是由于 Git-LFS 中的一个 buglet，其修复(或至少是变通方法)在一个稍微更新的 Git-LFS 版本中。

见 https://github.com/git-lfs/git-lfs/issues/1880和 https://github.com/git-lfs/git-lfs/pull/1932有关错误和修复/解决方法的描述。

这是我的胶囊摘要:

当您使用 Git-LFS 时，您的标准 Git 配置被修改为使用 Git 的清洁和污点过滤过程。污点过滤器旨在“弄脏”从版本控制系统出来的文件，而干净过滤器是其逻辑对立面:它清理文件以存储在 VCS 中。要使用此类过滤器，您必须同时标记您的 .git/config文件和您的 .gitattributes文件; Git-LFS 会自动为你做这个标记。

作为一个有点愚蠢的例子，有些人喜欢让每一行都以 CR-LF 结尾，而不是一个换行符(仅 LF)，但存储文件的版本控制版本并带有换行符结尾。 Git 可以直接执行此操作(使用行尾过滤器)，但如果出于某种原因您想自己编写程序来执行此操作，则可以使用污迹过滤器将 LF-only 替换为 CR-LF，并使用干净的过滤器以仅用 LF 替换 CR-LF。然后，您的工作树文件将具有所需的 Windows 样式行尾，而您提交的文件将具有所需的 Linux 样式行尾。

更实际的是，有些人喜欢扩展关键字(例如，RCS 或 CVS 之类的 $Id$)。 Git 还包括一个内置的 ident专门为 $Id$ 执行此操作的过滤器.将文件提取到工作树时完成扩展(就像通过污迹过滤器一样)，并删除 - 放回 $Id$ — 添加文件以进入新提交时。1 如果您想处理更多关键字，例如 $Log$ ,2 您必须编写自己的过滤器。

Git-LFS 所做的是使用(滥用？)clean 和 smudge 过滤器，用特殊修饰的哈希 ID 替换大文件，这些哈希 ID 充当外部大文件存储的“指针”。这样，Git 就从不存储——甚至从某种意义上说——根本看不到大文件。它只看到并存储这些经过修饰的哈希值。 Git-LFS 过滤器负责在 checkout 时用实际的大文件内容替换有趣的哈希值，并在 git add 用有趣的哈希值(新的或适本地重新使用)替换大文件内容。时间。

但是有一个技术故障:Git 使用管道来实现污迹和清洁过滤器。 (这些管道最近变得很花哨；参见 the Long Running Filter Process section of the gitattributes documentation 。)Git-LFS 代码和 Git 代码本身必须小心不要“便秘”管道……而且，事实并非如此。 (有关一些详细信息，请参阅 my answer 到 live output from subprocess command。)

1 具体来说，当文件从 Git 的索引复制到工作树时，涂抹过滤器(以及 ident 和任何行尾黑客)会应用于文件。当文件从工作树复制到索引时，干净的过滤器会应用于文件。由于提交的树仅从索引中找到的文件构建，并且索引版本始终是“干净的”，因此所有提交也始终是干净的。

2什么$Log$在 RCS 和 CVS 中所做的是扩展到文件的整个日志消息历史记录——本质上，所有触及文件的提交，除了 RCS 和 CVS 是基于文件的而不是基于提交的——以便历史记录在那里在编辑文件本身时。之前实际使用过这些东西，我坚信这是一个坏主意:这种元数据只属于版本控制系统(与 Git 或 Mercurial 一样，应该由有权访问整个存储库的开发人员分发)。尽管如此，还是有人喜欢这样，而且在技术上可以在 Git 中做到这一点。