在 git 分支名上面加斜杠真的太恶心了

[itskingname]

不知道谁开的头，git 分支名写成这样：feature/xxx

这样写会让人有时候分不清楚 git 命令自带的斜杠和这个手动加的斜杠。例如:

git merge origin/feature/xxx 
git push origin feature/xxx:feature/xxx

直接使用下划线甚至驼峰明明都比乱加斜杠好：

git merge origin/feature_xxx
git push origin featTest:featTest

最恶心的是，如果本地已经有一个 feature 分支了，那么再创建 feature/xxx 分支就会报错：

```
fatal: cannot lock ref 'refs/heads/feature/xxx': 'refs/heads/feature' exists; cannot create 'refs/heads/feature/xxx'
```

我觉得楼下这些赞成使用/的人，就跟那些赞成 Java 项目里面文件夹嵌套几百层的人是同样的人。

把一个错误的糟糕的恶心的实践当成最佳实践。然后还觉得其他人的做法有问题。

[ZhiAn]

因为分支加斜杠，会在图形化 git 工具是显示为文件夹（入行时某位前辈说的）
比如
-feature
-xxx
-xxxx
-fix
-xxx

[superchijinpeng]

这不是通用的吗，/ 代表文件夹

[superchijinpeng]

@superchijinpeng 下划线也不好，最好 -

[jfcherng]

把 remote 的名稱也加上斜線 (狗頭

[jhdxr]

我就是用斜杠的，理由 1L 说了

区分不出和 git 自带的是什么鬼？一般不就是有个 origin/的前缀么？就算有别的 remote 也不会太多，不至于会和这些 branch 搞混吧

[Kaiv2]

我的习惯是使用 -

[shuoxianSun]

谷歌了一下 好像 " - " 符号是一个比较好的方式

[Vegetable]

因为人家本来就支持这么做
你非得说建一个分支叫 origin/master ，那确实有点不好，但是 feature/{feature}有什么问题，什么地方分不清

[blinue]

@ZhiAn #1 斜杠的效果：

[NerbraskaGuy]

用 sourcetree 这种的不分类成文件夹，找分支能找半天

[kneo]

不明白为什么会分不清。我没看出来会和什么弄混。可能就是你不习惯而已。

[sunznx]

感觉不用 / 的才是异类

[allplay]

我不搞开发，但 git 名称内含斜杠，在本地文件系统里岂不成了非法字符？

[wumou]

https://dev.to/basementdevs/be-a-better-developer-with-these-git-good-practices-2dim

[dif]

我一般都中划线 feat-xxx,hotfix-xxx 。。。。 反正不管哪个，统一就行，只是为了区分，识别，只要 git 支持，那就没毛病。

[linauror]

感觉这样挺好的 － O －

[inhzus]

呆过几家大厂大家都这么做。举例 alice/240426_fix_bug

[yinyu]

我同事写了个对比 git 俩分支然后生成 releasenote 的工具，结果因为这种分支名，在最后生成结果的时候报错，找不到路径，笑死

[Colderer]

@sunznx #12 这种就是所谓的二极管？

[iosyyy]

@superchijinpeng #3 - 有歧义 / 可以视为这种文件夹

[wuxidixi]

额，我们这么做好几年了，feat fix 啥的，分开看的清晰一点啊

[iosyyy]

@superchijinpeng #3 我的 是下划线上班上傻了以为是“\”

[vacuitym]

这不是正常的 git flow 流程吗

[zsk425]

又学到一个小技巧😄

[28Sv0ngQfIE7Yloe]

feature/module-name

hot-fix/issue-023

有什么问题？

[Baymaxbowen]

[g0python32]

有什么问题吗

[crackidz]

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

[EastLord]

用/ 挺正常的 ，但我们公司用_

[huzhizhao]

不管怎么样 跟着大家都一样就行 虽然我也是/

[zylll520]

/ 挺好的呀，在 Tower 里面代表文件夹，相当的舒服

[mouyase]

菜，就多练。

[dapang1221]

啊我刚知道这个还能带斜杠，好，决定了，以后的分支名全加上斜杠

[lei2j]

用斜杠不是很常见吗

[kangwei]

当项目大了，维护人多了，分支超多了，你就知道 git 有/ 多好

[iugo]

对于分支名, 我们要求只用 "-".

[Chad0000]

我用 Sourcetree ，不管多少字符的分支名，都右键，Merge 。珍爱生命，远离命令行。

[catamaran]

sourcetree 难用，试试 fork

[ooops]

相同的不用写，所以简单规则 git push 就完事。merge 的时候 origin 应该很好分辨，而且你大部分时候也不需要 origin 。所以很难混淆

[yuancoder]

会在 .git 下面生成对应的目录

例如分支：feature/mytest

.git/refs/heads/feature/mytest

[my3157]

git flow 工具默认的分支规则就是这样，feature/*，release/*，hotfix/*，support/*

[Alliot]

这是 git flow 的做法。。有什么不合理的吗

[fxjson]

有逗号、&符都很恶心

[NotFoundEgg]

不光 git 分支名的斜杠支持文件夹折叠，redis 的 key 也是这样（在某些 gui 里

[simen513]

/ 代表文件夹，如果是大项目，有很多人一起提交代码，包括 review 代码等，不同的人创建的分支都放到自己名字的目录下，这样好管理和查找。如果是小项目自然是无所谓了。

[est]

哈哈哈哈，恭喜 LZ 被一群 GUI 工具党教育了。。。。。。

我也是习惯 CLI ，但是的确这个命令对有歧义的地方处理得很糟糕。。。

[DesnLee]

@est 我觉得 GUI 不 GUI 并没有什么高低，用 GUI 也不一定不会命令行，只是有些操作 GUI 确实很方便就是。

我在用 Gitkraken ，支持内建终端，可以 GUI 配合命令行操作 git ，过于好用入了正版，我就在它里面同时用 GUI 和命令行。

[est]

@DesnLee 就从分支名字包含斜杠来说，GUI 就直观的多，CLI 就遭罪，这明显是有高低的。

我 10 年前见过最搞笑的是有人把本地 hg 仓库起了个中文分支名字，推到服务端，hg web 挂了。。。233333

[m1nm13]

这...真不是 GUI 的 BUG,结果被当 feature 吗

[loveyu]

之前用斜杠，后来起名字困难，改为分支名直接使用需求 id

[jinliming2]

感觉 git 本身就是这么设计的啊，分支就是文件夹。
分支分为本地分支和远程分支，本地分支在 .git/refs/heads 下，以斜杠为目录存储，比如 main 、feat/feat1 ；远程分支在 .git/refs/remotes 下，以远程名与分支名用斜杠分隔，按目录来存，比如 origin/main 、upstream/feat/feat1 。
远程名里也是可以包含斜杠的，所以你的上游不仅可以叫 origin 、upstream ，也可以叫 upstream/cn 、upstream/us 。
所以远程分支也可以是 upstream/cn/feat/feat1 ，其中 upstream/cn 是远程名，feat/feat1 是分支名。

不过，这个确实可能会存在冲突的问题，比如你本地一个分支名就可以叫做 origin/main ，这样就会和 remotes/origin/main 冲突，在 git checkout origin/main 的时候就会收到警告：warning: refname 'origin/main' is ambiguous.。这时候实际上切换到的是本地的分支，要切换到远程分支进入 detached HEAD 状态，需要指定 git checkout remotes/origin/main 。
而如果本地有个分支叫做 remotes/origin/main 的话，又会冲突，那要切到远程分支就要指定 refs/remotes/origin/main 。
如果本地又有了 refs/remotes/origin/main 分支了，emmmm ，应该就没办法直接用分支名来切换了。

[fpk5]

@allplay #13 git 包含/，在文件系统里面就是作为路径存的，`feature/abc`就是一个 feature 目录底下一个 abc 文件，文件里面是 commit 的 hash

[fpk5]

@est #46 包含/的 ref 表示为目录，这是 git 自己的设计

[fpk5]

@jinliming2 #51 实际上你不能创建 refs/remotes/origin/main ，因为这个已经存在了。

[dobelee]

斜杠不是自己加的，git flow 的默认规范，CLI 和 GUI 都能自动创建。

[geelaw]

按照这个逻辑分支的名字同时可以是文件名也恶心，毕竟无法区分 git checkout master 的意思是提取当前 commit 里当前目录下叫做 master 这个文件，还是指切换到 master 这个分支，尤其是在最近的改名浪潮下，master 并不一定是存在的分支呢~

建议以后分支都取不能是文件名的名字，但很可惜 Git 支持的分支名全是 Linux 下合法的文件名，所以推荐不要使用 Git ，免得造成歧义。

[jinliming2]

@fpk5 #54 刚试了，是可以的

[skydiver]

有的公司禁止用斜杠，因为会给服务器创建太多目录…有的设计不好的服务端还会崩

[Trim21]

不说 guicli 的问题了，origin/feature-xxx 跟 feature/xxx 里面这两个斜杠的语义是相同的啊…

[infoscope]

idea 按/生成多个仓库的目录，按规范命名，一次就可以找到一个需求所有的仓库

[AquanllR]

/ 图形化会按文件夹分类

[xqcokid]

可命名时又没有任何校验

[est]

@jinliming2
@fpk5

还是还有问题，文件名也可以支持冒号的。。。。还有如果我创建两个点 .. 的分支名，又会发生什么呢？ 23333

都不想去试了。。。

[Katrol]

确实不应该用斜杠，方式解决可以加下划线，或者把 feature 、origin 这种挪到后面一点

[est]

@Katrol 斜杠可以用，git 这命令行设计得问题有点多而已。。。。

[Nasei]

你没有搞明白，一个是不存在 git 命令自带的斜杆，一个是那个所谓的自带斜杠，跟自己加的斜杠，作用是一样的，本来就是这么用的

[shenke]

同用/

[uSy62nMkdH]

@superchijinpeng 我倒喜欢下划线，因为很多编辑器针对类似于:feature_xxx_xxx 和 feature-xxx-xxx ，前者双击可以选中想要的分支名，后者要只能选中某个单词

[wangsijie]

这哪里份不清了

[chenxytw]

这个其实是个人喜好问题，我觉得没必要成为矛盾点。
主要是目前主流使用 git 的方式比较垃圾，明明是一个分布式 cvs, 却硬生生的用成了中心化的 cvs 。
参考一下 linux kernel 的使用方式，主线只有一个 repo 也只有一个 branch ；日常开发都在很多很多很多 repo 上，
每个人自己本地的 repo 爱咋搞咋搞，你作为上游合并代码的 maintainer 也看不见对方私底下到底是咋样的 workflow
这个也可以参考 Linus Torvalds 的(观点)[https://yarchive.net/comp/linux/git_branches.html]，私底下自己的 repo 爱咋搞咋搞，只要最后提交给他的 pr 是干净的就行了。

[alanhe421]

无知而已

[securityCoding]

用 fork 模式，个人私仓爱咋滴咋滴

[zizon]

/的一个问题是有时候你做自动化脚本会遇到路径问题.

比如你根据分支名字去打包,然后期望的是文件实际路径变成了 nested 的目录.

[jameszhangqk1]

程序员的“恶”趣味。

[jameszhangqk1]

我来一个：PHP 是世界上最好的语言！

[lslqtz]

更有可能是 merge 的 origin 不应该使用斜杠, 而不是分支不能使用.
git merge origin/feature/xxx
git push origin feature/xxx:feature/xxx

上面举的例子已经很明确了, 源是源, 分支是分支, 第一种方式本质上是一种把源和分支混淆的简化写法.

[lslqtz]

在我看来, 分支用斜杠是很正确的方式, 因为斜杠已经被用于文件夹, 而分支分类的方式按约定俗成的方法沿用斜杠做分类降低用户理解难度, 从结果看并没有什么问题. 但如果从混淆的角度来看, 那 / 是不应该采用的, 因为它和文件夹太相似, 但问题在于, 参数它是有顺序的, 你把文件路径当分支传入那本质上应该归类于你的使用问题, 如果因为相似就不使用, 那相似的特殊字符实在有太多太多. 好的做法是在各个命令中能有相似的命令格式, 即意味着传入参数的基本可以大致相同, 而就我上述提到的 git merge 和 git push 以 1L 提出的格式的话就不符合这点, 所以它的问题是不同参数的区分度不够.

[andyiac]

分支以自己的名字加斜线开头 name/ ，组里人多时在 gitgui 工具里比如 source tree 可以快速找到自己或别人的某个分支

[kylix]

这不是 git flow 的标准做法吗？不喜欢就不用呗。没必要说恶心之类的。

[daoqiongsi1101]

feature/itskingname/image-v1

比如你开发某个 feature ，分支可以这样命名

[IamUNICODE]

新技能 get

[jqtmviyu]

哈哈, 有大佬教下如何在本地已有 dev 分支的情况下, 创建 dev/feat1 的方法吗?
cli 直接报错, 除非删掉本地的 dev 分支.

[0xABCD]

下划线和驼峰都很丑

[alexmy]

以前公司是 feature-xx ，来新公司后改为 feature/xx
公司什么习惯跟着走就好咯。

[yc8332]

没搞懂这有什么问题。。。个人的问题多一些吧

[g0python32]

@jqtmviyu
git checkout dev
git checkout -b dev/feat1
这样子不行吗

[hupeng]

习惯用 CLI ，对于/完全没有好感，兼容性差，就是一个异教徒

[itskingname]

@g0python32 依然会报错

[ColdBird]

虽然我司用的 feature/，但是我才知道可以在 branchs 里看到 feature 文件夹

[unco020511]

其实用 GUI 工具就有优势了,仓库分支多的时候可以起到一个分类功能,不过我们是使用下划线,目前也是避免用斜杠

[DaneWalters]

没搞懂这个问题，这个不是很常见的用法吗。很多分支还会要求你这样写 feature/{yourName}/xxxxxx 这个和 cli 没啥关系吧。多练练吧，不行就看官方的《 pro git 》

[g0python32]

@itskingname 你...真的...会....使用....git....吗?

[shunia]

分支特别多以后，如果不用斜杠很恐怖，无论是用 cli 命令+auto completion 还是在 gui 里通过树状结构，查找某一个分支的过程都会让你崩溃。尤其是当前分支上有 tag/release 的 workflow 的话，你会发现一段时间过去，几乎 90%都是 tag 和 release 分支，当需要回溯查找其中某一个分支时的体验很噩梦。

我个人感觉使用斜杠最大的作用其实相当于编程里面的领域区分，有的项目会推荐以开发者名字为区分，更多的项目会推荐以分支的特性作为区分比如很常见的 feature/fix/release 。

关于方便与否或者说甚至分支报错的问题，看 OP 的描述其实更多的是在某种规则体系之下非要不遵循规则操作而已。比如说既然采用了下划线加分支特性区分的前提下，什么人会推一个名为 feature 的分支来让所有人都无法创建 feature/*分支？

另外再说一下类比，我觉得这个区分方法就跟管理项目目录一样的，甚至目录管理还要区分大小写呢，比分支基本都建议小写还要磨叽。

[wanniwa]

你没用过 idea 吗，idea 里面 feature/xxx ，自动会帮你 feature 下的聚合在一起当一个文件夹，你分支建了一堆的时候就有用了。我估计你不知道/的作用所以吐槽

[zealotpuppy]

@est 我始终没看明白哪里有歧义，/不就是目录吗？ git 相比普通文件系统无非多了个限制，不允许目录和普通文件重名，这很好啊。我自己就是用 cli ，没觉得有什么需要特别注意的。可能需要多敲一 f 的单词
ls .git/refs/heads/feature 看到的就是 feature/前缀的分支名，不觉得有什么奇怪的。
既然 git 原生就支持/作为目录，那我觉得设计理念里就有建议大家使用/来区分的意思。当你有一堆文件，我相信大家都不会全部放在一个目录里吧，都会按领域分到不同目录，git 里的/就说这么设计的啊
我基本也不是手动写 push 分支，alias gpsup='git push --set-upstream origin $(git_current_branch)'够用
@est

[zoffy]

如果你把 origin/feature/xxx 理解为 string[]，那确实不合理，但这时你想要的结构其实是
{
remote: string
group?: string
name: string
}

如果你把 origin/feature/xxx 理解为 tuple ，那就是合理的，并且是简单的

[est]

@zealotpuppy 道理是这个道理。但是命令行那个「格式」 不友好

[JsonLee]

@jqtmviyu 不能，每个分支在 git 中实现都对应了.git/refs/heads/目录下的一个文件，‘/’对应文件夹，你不能在一个文件夹下创建相同名字的文件或文件夹。

[th3ee9ine]

feature/xxx
fix/xxx
这种方式并没有啥问题，代表的是某种功能分支，进行归类罢了。

至于楼主说的一个问题：“如果本地已经有一个 feature 分支了，那么再创建 feature/xxx 分支就会报错”，这是属于楼主使用问题，你去 linux 下创建一个 123 的文件‘touch 123’，然后再创建 123 的文件夹同样是不能创建的。你要么当‘feature’为一个分支，要么把 ‘feature’ 当做一个文件夹。而不是又要，既要，然后吐槽为啥不行，报错的本质，是你使用方式不对。

[Nile20]

/有特别的使用场景，我前面好像没有人提到：在需要管理复杂的推送逻辑，比如 QA 团队的 master 分支 push 时自动进 qa/master 、开发的自动进 dev/master ，又或者同时维护多个 remote 时，往往需要定制 refspec：而 refspec 是不能基于名称的统配符的，只能基于路径统配符。例如不能写
fetch = +refs/heads/qa*:refs/remotes/origin/qa*
只能写
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*

把超出你理解能力的功能特性称为“恶心”，那我只能说菜就多练，吃不了这碗饭就别吃。