git 为什么分支名称不能包含“空格”字符？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6619073/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why can't a branch name contain the 'space' char?
提问by WinWin
I tried:
我试过：
git branch "MyProj/bin/ ignored"
and received:
并收到：
fatal: 'MyProj/bin/ ignored' is not a valid branch name.
The git-branchman page points to the git-check-ref-formatman page to get the actual rules for a valid branch name.
在混帐分支男子网页指向的git检查-REF-格式手册页，以获得实际的规则，一个有效的分支名称。
Sure enough, the reason for the above fatal error appears to be the inclusion of a space character.
果然，上述致命错误的原因似乎是包含了空格字符。
Any idea why, in this day and age, spaces are still excluded from a branch name (I would have expected it in ancient CVS, for example, but Git?)
知道为什么在当今时代，分支名称中仍然不包含空格（例如，我本希望在古老的 CVS 中使用空格，但是 Git？）
What could be valid technical reasons for that?
什么可能是有效的技术原因？
回答by shelhamer
I do not know if you are going to find a pure, technical reason down at the bottom of this. However, I can offer that spaces tend to throw wrenches in all sorts of *nix utilities and filename processing, so it may have been to avoid accidentally doing anything wrong further down the line. After all, a git branch boils down to a file in the repo and this avoids dealing with spaces in that file's name (specifically, a branch is a file in .git/refs/heads/, as mentioned in the comment).
我不知道你是否会在这底部找到一个纯粹的技术原因。但是，我可以提供空格往往会在各种 *nix 实用程序和文件名处理中引发麻烦，因此可能是为了避免意外地进一步做错任何事情。毕竟，一个 git 分支归结为 repo 中的一个文件，这避免了处理该文件名中的空格（具体来说，一个分支是 .git/refs/heads/ 中的文件，如评论中所述）。
Mostly I would guess the reason is philosophical, and meant to keep things simple. Branch names are human-readable names that have no real reason to be complicated (and require typing two extra chars each time haha, to invoke the ghost of the sysadmin who has aliased every command to an indecipherable three letter combination). Otherwise known as the "why cd is not chdir" argument.
大多数情况下，我猜原因是哲学上的，旨在让事情变得简单。分支名称是人类可读的名称，没有真正复杂的理由（并且每次需要输入两个额外的字符哈哈，以调用系统管理员的鬼魂，他将每个命令别名为一个难以辨认的三个字母组合）。否则称为“为什么 cd 不是 chdir”的论点。
回答by joe
old thread, but hey..
on a mac i use alt + space. it's gonna add an invisible character that will do the trick for you. mind: it's not a 'space', it's an invisible character. visually the same thing, but effectively not the same. 100% likely going to confuse the hell out of anyone else and definitely going to bring chaos everywhere, but hey, for the kicks.. why not? xD
旧线程，但是嘿..
在 mac 上我使用 alt + 空格。它会添加一个隐形角色来为你解决问题。注意：它不是一个“空间”，它是一个隐形字符。视觉上是一样的东西，但实际上不一样。100% 可能会混淆其他任何人，并且肯定会到处带来混乱，但是嘿，为了踢......为什么不呢？xD
git checkout -b US24024?Automated?Tests?-?Profile?A
Switched to a new branch 'US24024?Automated?Tests?-?Profile?A'
git checkout -b US24024?Automated?Tests?-?Profile?A
Switched to a new branch 'US24024?Automated?Tests?-?Profile?A'
回答by Vir
There is a possible workaround if you are desparate enough. There are a lot of space-like characters in the unicode set. But only U+0020 is the space that is disallowed. Take e.g. a non-breaking space and you can have a branch name with spaces. The main issue is that your keyboard likely has no key for that code point. I use the following script to work around that issue:
如果你足够绝望，有一个可能的解决方法。unicode 集中有很多类似空格的字符。但只有 U+0020 是不允许的空间。以一个不间断的空格为例，你可以有一个带空格的分支名称。主要问题是您的键盘可能没有该代码点的键。我使用以下脚本来解决该问题：
#!/bin/zsh
git co -b "${@// /?}"
It simply replaces all spaces in the arguments with non-breaking spaces...
它只是用不间断空格替换参数中的所有空格......
回答by kelvin
Because using path names correctly in shell scripts is hard. From the linked
git check-ref-formatman page itself:
因为在 shell 脚本中正确使用路径名是很困难的。从链接的
git check-ref-format手册页本身：
These rules make it easy for shell script based tools to parse reference names, pathname expansion by the shell when a reference name is used unquoted (by mistake), and also avoid ambiguities in certain reference name expressions (see gitrevisions(7)):
这些规则使基于 shell 脚本的工具可以轻松解析引用名称，当引用名称不加引号（错误地）使用时由 shell 进行路径名扩展，还可以避免某些引用名称表达式中的歧义（请参阅 gitrevisions(7)）：
See also Filenames and Pathnames in Shell: How to do it Correctly:
The basic problem is that today most Unix-likes allow filenames to include almost any bytes. That includes newlines, tabs, the escape character (including escape sequences that can execute commands when displayed), other control characters, spaces (anywhere!), leading dashes (-), shell metacharacters, and byte sequences that aren't legal UTF-8 strings.
基本问题是，今天大多数类 Unix 允许文件名包含几乎任何字节。这包括换行符、制表符、转义字符（包括可以在显示时执行命令的转义序列）、其他控制字符、空格（任何地方！）、前导破折号 (-)、shell 元字符和不合法的字节序列 UTF- 8 弦。
...
...
However, this flaw in Unix-like kernels (allowing dangerous filenames)combines with additional weaknesses in the Bourne shell language, making it even more difficult in shell to correctly handle filenames and pathnames. I think shell is a reasonable language for short scripts, when properly used, but the excessive permissiveness of filenames turns easy tasks into easily-done-wrong tasks.
然而，类 Unix 内核中的这个缺陷（允许使用危险的文件名）与 Bourne shell 语言中的其他弱点相结合，使得 shell 更难正确处理文件名和路径名。我认为 shell 对于短脚本来说是一种合理的语言，如果使用得当，但是文件名的过度宽容会将简单的任务变成容易做错的任务。
回答by Catalin Popescu
It's not allowed because it would complicate the functionality of the "git checkout" command.
这是不允许的，因为它会使“git checkout”命令的功能复杂化。
Ex: Consider you currently have a branch called , although you are currently in the master. If you would run the command
例如：考虑您当前有一个名为 的分支，尽管您目前在 master 中。如果你要运行命令
(master): git checkout -b my fix
(master): git checkout -b 我的修复
git would not know if you want to make a new branch called "my fix" or if you want to make a new branch called "my" that is linked to your original "fix", rather than the "master" branch.
git 不知道您是要创建一个名为“my fix”的新分支，还是要创建一个名为“my”的新分支，该分支链接到您原来的“fix”，而不是“master”分支。
Source: https://git-scm.com/docs/git-checkout(Git Documentation)
来源：https: //git-scm.com/docs/git-checkout（Git 文档）
