刚接手团队Git规范时，我第一件事就是让所有人统一分支命名。这里先回答那个最常被问到的问题：分支名到底能起多长？

长度限制在哪一层？

Git分支名长度上限不是由Git硬性规定，而是受底层文件系统限制。常见文件系统（如ext4、APFS）单个文件名上限为255字节，而Git会把分支名直接作为文件路径存储，因此分支名通常不能超过255字节。在Windows上，受路径总长度限制，分支名过长会更容易触发“Filename too long”。如果创建分支时报错“cannot lock ref”，可以用 `git check-ref-format --branch` 检查名称是否合法。

`cannot lock ref` 这个报错我在老项目里碰到过一次，通常是某个迭代分支名带了完整需求标题，加上前缀后直接爆掉。你不需要去数每个字符，只要先确认是这个问题，然后重命名分支就行。

为什么不要顶着上限起名

为了避免分支名超长，建议将分支名控制在80字符以内。虽然实际限制可能放宽到255字节，但过长的分支名在命令行、CI日志、代码评审工具中都会被截断，反而增加沟通成本。一个可行的命名规范是`/`，例如`fix/login-error`，如果必须关联需求单，用`feat/1234-user-profile`，不要一次性把整个标题粘贴进去。这样既保留关键信息，又保证可读性。

这个斜杠分隔符用来隔开类型和描述，类型通常只有一两个词，描述控制在三四个词。比如说，同样一个修复登录页错误的分支，`fix/login-error` 一眼就能看懂；而 `hotfix/login-page-validation-missing-email-format-check-late-night` 在终端里直接超出可视区域，在PR页面上也会被截断，评审者还得点开才能知道干了什么。

多字节字符的长度陷阱

分支名的长度限制与文件系统编码有关。如果用了中文或其他多字节字符，一个字符可能占用3个字节，那么能容纳的字符数会少于255个。比如在UTF-8环境下，90个中文字符可能就接近270字节，直接超过上限。这不是Git的问题，而是路径存储单元的字节限制。因此在团队里，应该约定分支名只用ASCII字符，从根上避免因字节数超限导致推送失败。

我之前见过一个中文分支名“修复登录页用户头像显示异常”在Linux上能创建，在Windows上却报错，原因就是不同文件系统的编码处理方式不同，虽然都是UTF-8，但路径总长度限制不一样。所以我的建议是：团队规范里直接禁用非ASCII字符，别去赌环境。

用命令快速确认分支名是否合法

在创建分支前，可以用 `git check-ref-format` 做语法检查。最常见的是这样：

git check-ref-format --branch "your-branch-name"

如果这个命令返回0（没有输出），说明名称合法；返回非0就表示有问题。它主要检查非法字符和引用格式，不包括长度。要检查长度，需要自己统计字节数：

echo -n your-branch-name | wc -c

注意这条命令里的 `wc -c` 统计的是字节，不是字符。如果你用了中文，这个数字会明显大于字符数。建议把这两步放进一个脚本里，在创建分支前直接跑一遍。

命名规范怎么定

命名规范不是越细越好，关键要能长期执行。我推荐用类型前缀加短描述，类型通常用 `fix`、`feat`、`chore` 这些，描述部分用小写英文，词与词之间用连字符。需要关联需求单时，把票号放在描述前，比如 `feat/1234-user-profile`。

另外，几个容易踩的坑也提一下：分支名里不要带 `#`，因为在shell里会被当成注释；不要以 `-` 开头，会被当成选项；不要包含 `..`，会引发引用解析歧义；不要包含空格，否则命令都需要加引号。这些都可以通过 `git check-ref-format` 命令预先发现，不用等创建分支后才暴露。为了保险，可以在 `.git/hooks` 里加一个预提交钩子，对分支名做长度和字符校验，避免有人绕过检查。

如果你已经在用一套比较乱的分支名，可以从下个迭代开始强制规范，老分支用 `git branch -m` 逐个重命名，不用一次性全部改完。重点是让新分支从创建那一刻就能被机器检查，而不是靠人眼去数。