在 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

[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/*

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