1

例如，假设我有

Directory/
      nameOfFile.txt
      nameOfDirectory/
                ...

我一直在使用这种格式git add Directory/nameOf*，但在不同的文档中，我见过git add 'Directory/nameOf*'.

刚试过git add "Directory/nameOf*"，它奏效了。

也尝试过git commit -m Message with no quotes，它也有效。

那么 Git 是否允许不可互换的引号/引号，或者这只是某些情况或版本？除了允许的范围之外，无引号、单引号和双引号的标准协议是什么？

4

4 回答 4

2

除非您使用一些奇怪的外壳，否则 git 不会看到这些引号。引号将被外壳剥离。使用引号会阻止 shell 解释*模式中的 git 。在许多情况下，这种类型的扩展是由 shell 还是由 git 完成并不重要，但有时它会像您在 git 索引而不是文件系统上操作git rm --cached.

引号还可以防止空格被 shell 解释为分隔参数。引用包含空格的单个参数几乎总是必要的。你给出的提交命令不应该工作，它不适合我。

通常，您使用的报价类型无关紧要。最常见的情况是，如果被引用的参数包含一种类型的引用，那么使用另一种可能会更容易，如果参数应该包含 a $，则使用单引号可能会更好。在双引号内，您可以使用\转义一个", $, 或 (another)\您想要按字面意思理解的。

于 2013-07-23T19:57:24.913 回答
2

这个问题真的与你的shell无关git，一切都与你的shell有关。

大多数 shell 使用空格“标记”命令行——也就是说，将其拆分为一系列离散元素。所以，例如...

rm one file

...将尝试删除一个名为的文件one和一个名为 的文件file，而...

rm 'one file'

...将尝试删除一个名为one file. 因此，对于您的示例，是否使用引号并不特别重要，因为您的文件名都不包含空格。一个例外是commit示例。如果message包含空格，您需要引用它，否则您将得到：

$ git ci -m this is a test
error: pathspec 'is' did not match any file(s) known to git.
error: pathspec 'a' did not match any file(s) known to git.
error: pathspec 'test' did not match any file(s) known to git.

事实上，还有一点值得考虑：引用文本通常会抑制通配符扩展，所以如果我有一个名为的文件nameOfFile.txt并且我这样做......

rm nameOf*.txt

...它会工作得很好，但如果我这样做：

rm 'nameOf*.txt'

...我会得到一个错误：

rm: cannot remove `nameOf*.txt': No such file or directory

git但是，如果外壳程序不这样做，它看起来实际上会执行文件名扩展，因此您的通配符示例将起作用。

于 2013-07-23T19:52:22.640 回答
0

它基于您正在使用的外壳。我只是用 \ 转义空格和其他字符

于 2013-07-23T19:50:31.283 回答
0

双引号会起作用，因为 shell 会处理它们，因此您可以在文件名等中包含空格。所以git add foo/bar与git add "foo/bar".

同样，git commit -m Foobar将与 相同git commit -m "Foobar"。在这两种情况下，git都将Foobar被视为定义消息的单个参数。但是，如果git commit -m "foo bar"与此相同git commit -m foo bar，则意味着git commit -m接受多个命令行参数并将它们拼凑在一起以形成您的消息（似乎很奇怪），因为在第一种情况下，它会看到单个消息文本参数，foo bar而在第二种情况下，它会看到单独的参数foo和bar。

于 2013-07-23T19:51:12.703 回答