在 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

[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 ，分支可以这样命名