Question

我的文件名包含空格，所以当我执行以下操作时：

git add first%20file.txt

上面的命令在我的控制台中返回了无效的路径

Answer 1

如何逃避空间：

git add first\ file.txt

Answer 2

正如sschuberth在评论中所提到的 - 您只使用%20来转义URL中的空格，而不是命令行中的文件名。

您有两种方法可以添加这些文件

1）转义文件名中的空格

git add first\ file.txt
git add first\ file\ name.txt

2）在引号

中添加文件名

git add "first file.txt"
git add "first file name.txt"

FWIW，如果您只有一个名称以字符串first开头的文件，您也可以使用制表符完成

Answer 3

Git 2.18应该改进文件名中包含空格的文件的完成（和Git 2.21，2019年第一季度一样，也应该看到这个答案的第二部分）

commit f12785a见SZEDER Gábor (szeder)（2018年4月16日）commit 6d54f52。

完成：改进命令行上的处理引用路径

我们的git-aware路径完成在必须完成时不起作用   已经包含带引号和/或反斜杠转义字符的单词   命令行。
  问题的根本原因是，完成函数会逐字地查看命令行中的所有单词，即包括shell在执行完成的命令时最终会删除的所有反斜杠，单引号和双引号字符。
  这些引用/转义字符会导致不同的问题，具体取决于哪些   要完成的单词的路径组件包含它们：
引用/转义位于前缀路径组件中假设我们有一个名为＆＃39; New Dir＆＃39;的目录，其中包含两个未跟踪的文件＆＃39; file.c＆＃39;和＆＃39; file.o＆＃39;，我们有一个忽略目标文件的gitignore规则。
在这种情况下所有这些：
git add New\ Dir/<TAB>
git add "New Dir/<TAB>
git add 'New Dir/<TAB>
应该唯一完成＆＃39; file.c＆＃39;马上，Bash同时提供＆＃39; file.c＆＃39;和＆＃39; file.o＆＃39;来代替。
  这种行为的原因是我们的完成脚本使用前缀目录名称，如＆＃39; git -C "New\ Dir/" ls-files ...＆＃34;，即反斜杠在双引号内。
  然后Git尝试输入一个名为＆＃39; New\ Dir＆＃39;的目录，它很可能会失败，因为这样的目录不存在。
  因此，我们的完成脚本不会列出任何文件，使COMPREPLY数组保持为空，这反过来又会导致Bash回退到其简单的文件名完成状态并列出该目录中的所有文件，即两者都是＆＃ 39; file.c＆＃39;和＆＃39; file.o＆＃39;。
引用/转义是在要完成的路径组件中我们假设我们有两个未跟踪的文件＆＃39; New File.c＆＃39;和＆＃39; New File.o＆＃39;，我们有一个忽略目标文件的gitignore规则。
在这种情况下所有这些：
git add New\ Fi<TAB>
git add "New Fi<TAB>
git add 'New Fi<TAB>
应该唯一完成＆＃39; New File.c＆＃39;马上，Bash同时提供＆＃39; New File.c＆＃39;和＆＃39; New File.o＆＃39;来代替。
  这种行为的原因是我们的完成脚本使用了这个＆＃39; New\ Fi＆＃39;或者＆＃39; "New Fi＆＃39;等词来过滤匹配的路径，当然，由于包含的反斜杠或双引号，所有潜在的文件名都不匹配。
  最终结果与上述相同：
  完成脚本没有列出任何文件，Bash回退到文件名完成，然后列出匹配的目标文件。

添加新的辅助函数__git_dequote()，该函数将从引用的单词中删除引用和转义。
  要最小化调用此函数的开销，请将其结果存储在中   变量$dequoted_word，应该在本地声明   呼叫者;只需打印结果就需要一个命令   替换强加fork（）子shell的开销   在__git_complete_index_file()中使用此功能取消当前单词，   即要完成的路径，以避免上述情况   引用相关问题，从而修复两条失败的引用路径   完成测试。

Git 2.21（2019年第一季度）将改进zsh＆＃34; git cmd path<TAB>＆＃34;已完成至＆＃34; git cmd path name＆＃34; 当完成的路径中包含特殊字符（如SP）时，不会尝试保留＆＃34; path name＆＃34;一个文件名。

已经修复此问题，以便将其完成为＆＃34; git cmd path\ name＆＃34;就像 Bash完成确实。

commit 7a478b3见Chayoung You (yous)，Junio C Hamano -- gitster --（2019年1月1日） ^{（由commit b84e297合并于commit f12785a, Git v2.18.0-rc0，2019年1月18日）}

completion：将git ls-tree的结果视为文件路径

我们假设有一些名为＆＃39; foo bar.txt＆＃39;和＆＃39; abc def/test.txt＆＃39;在   库。
  当以下命令触发完成时：
git show HEAD:fo<Tab>
git show HEAD:ab<Tab>
完成结果为bash / zsh：
git show HEAD:foo bar.txt
git show HEAD:abc def/
如果两者在路径中都有未转义的空间，那么他们就会被Git误读。
  git ls-tree的所有条目都是文件名或目录，因此__gitcomp_file()是正确的，而不是__gitcomp_nl()。

请注意正确处理引用路径的{{3}}   像这种情况一样，我们应该为$cur_案例取消引用?*:*。

例如，假设有未跟踪的目录＆＃39; abc deg＆＃39;，然后触发完成：
git show HEAD:abc\ de<Tab>
git show HEAD:'abc de<Tab>
git show HEAD:"abc de<Tab>
应该唯一完成＆＃39; abc def＆＃39;，但bash完成了abc def＆＃39;和＆＃39; abc deg＆＃39;代替。

在zsh中，触发完成：
git show HEAD:abc\ def/<Tab>
应该完成＆＃39; test.txt＆＃39;，但什么都没有   这两个问题将通过取消引用路径来解决。

__git_complete_revlist_file()将参数传递给__gitcomp_nl()其中   第一个是类似的列表：
abc def/Z
foo bar.txt Z
其中Z是EOL。
的标记
__git ls-tree | sed中blob的尾随空格。
它使完成结果变为：
git show HEAD:foo\ bar.txt\ <CURSOR>
因此Git会尝试找到名为＆＃39; foo bar.txt＆＃39;的文件。代替。
__git ls-tree | sed中树的尾部斜线。
它使zsh上的完成结果变为：
git show HEAD:abc\ def/ <CURSOR>
这样就可以在zsh上删除命令上的最后一个空格，以完成＆＃39; abc def/＆＃39;下的文件名。

对于Git控制台中的文件名空间，路径不能与％20一起使用

3 个答案:

完成：改进命令行上的处理引用路径

`completion`：将`git ls-tree`的结果视为文件路径

对于Git控制台中的文件名空间，路径不能与％20一起使用

3 个答案:

完成：改进命令行上的处理引用路径

completion：将git ls-tree的结果视为文件路径

`completion`：将`git ls-tree`的结果视为文件路径