git CLI 设计太烂

[AndyAO]

自己用 git 之后，感到由于知识不系统，很多问题都解决不了，就照着《 Git 权威指南》学完。

回想起自己没这么干之前，最大的误解就是认为 git 是 linus 的伟大作品设计是很好的，但是仅从命令行的设计来看，这个东西是极烂的。

如果你上手之后发现总是很难用，有时候很让人困惑，那么不要感到很自卑，本来就很难用，本来就很复杂。

StackOverFlow 上排名前 5 的问题中有 3 个和 Git 有关，这说明大多数工程师在使用中经常会感到困惑。

如果你感觉很简单，那么要不就是「专家谬误」，要不就是你天赋异禀，异于常人。

具体来讲，最容易被看到的设计硬伤是：

• 单个命令的功能太多
  • 例如，git reset 子命令，功能是名不副实的
• 概念命名随意
  • 例如，「暂存区」有多个名字，包括index，stage和cache
• 参数设计随意
  • 例如，git brach -b 等价于 git branch 后跟 git checkout

实际上，工具越出名，越底层，改进的空间越小。

像编程语言这种东西，基本上就是没有后期修改的，稍微动动就是鬼哭狼嚎的。

例如，Java 字节码自从诞生之后就基本上没改过，连向后兼容的更改都没有。

git 这些 cli 不是精心设计的，被精心设计的只是核心原理，cli 的各种功能是堆出来的，可以说基本上就没有什么设计可言，这个鬼样子也是可以理解的。

等到感到不改不行的时候，往往就已经晚了。

[okayan]

有一说一，我觉得楼主说的有道理

[yohole]

git 的 cli 个人也认为对不起它本身的名气和伟大，我接触了一年多的时候，依然用起来很生涩，直到后来全面切换到 JB 全家桶，才发现最好的 git GUI 其实就是 JB 家全家桶自带的

[mingyoung]

明明是人不行为什么要怪工具，哭嘤嘤

[peterswan]

我感觉 git 的命令没有说的那些问题啊，下面一条条对应 OP 所说的：
单个命令的功能太多，这个我不同意，命令都是有一个功能，这需要理解他的功能，比如 git reset 其实就是将当前 Head 指针进行 reset 一下
概念命名随意，也许存在不同表述的问题，但是表示的是暂存区这一块内容思想，和 git git cli 都没任何关系，只是外界表述问题
参数设计随意，你提出的那个 git checkout -b ，这个有任何问题么，本来的作用是切换分支，加入-b 让他新建一个分支而已。

我感觉你的吐槽是不成立的。个人并没有感觉 git 有这些问题。

[xiaolanger]

楼主喷在了点上挺好的

[hatsuyuki]

楼上一些人可能是文盲，看到关键字就开喷了，楼主明明说的是 Git CLI 设计的问题，又没说 Git 不好

[starsky007]

基本上同意楼主的观点。Git 设计得不够人性化、用户体验不好、学习有点难度。另一个类似的例子是 Linux OS 对比 Windows 、MacOS ，随便举个例子比如没有回收站，用户体验差，却被包装成 Linux 设计哲学。大多数场景下，**命令行是落后生产力的代表**，学习难度大、使用过程中容易犯错、容易遗忘。但是，迫于 git 相比 SVN 确实有优势、只是稍微难一点，还是建议楼主使用 GUI 工具，推荐 Fork 。

[SSang]

问题不大，我一般 bash_aliases 再套一层，不然根本记不住

[secondwtq]

Linus 可能对潜水更有兴趣

> cli 的各种功能是堆出来的
不仅限于 Git ，可以参考下这个 https://danluu.com/cli-complexity The growth of command line options, 1979-Present

> 实际上，工具越出名，越底层，改进的空间越小。

其实我觉得抛开原 Git CLI 那一套东西，有没有一种可能，我是说，有没有一种可能，包装出适用于特定工作流的工具，无论是 CLI 还是 GUI 。可能没法很好兼容 GitHub 等现有工具，但是至少做到单独使用比较流畅。类似的想法楼上也有，但是我觉得目前大多数基于 Git 的工具，都还是需要对 Git 的底层原理有一定理解，最后导致多少还是不得不尝尝 Git CLI 的美味。如果只是针对特定工作流做，或许能把原理也给简化掉。

[Buges]

https://www.yinwang.org/blog-cn/2015/03/11/git-etiquette
楼上一些人的反应简直一模一样。
另外其实 git 的内部实现也挺烂的，存储效率低下，大型二进制文件变更一点体积增加一倍。类似的 ostree 效率就高的多。
其实 mercurial (hg)是个不错的 SCM ，可惜功能比 git 相差甚远。

[zisen]

@SimonOne 29 楼提醒了我楼主标题写的就是 git cli 而不是 git 全部，cli 部分确实不够自然

[rioshikelong121]

git cli 不是 Linux 设计的。现在用的这些都是高层封装。

[24bit]

忘记是什么地方看到的了，linus 做出来 git 的时候好像就只有 cat-file 、update-index 、write-tree 这些基础命令，但是这些命令直接拿来用太难了，就又有人在这些命令的基础上包了一层 add 、status 这些命令。

也许别人那会想的也就是能用就行，哪想到现在使用会这么广泛

[zxhe]

有王垠那个味了

[yidinghe]

有道理，楼主可以封装一下，搞个项目叫 mygit

[liuzhedash]

楼主喷的点没有问题，git cli 确实不好理解也不好学习。
我觉得想搞好软件开发，首先得有点对代码设计的品味，接口叫啥名参数叫啥名其实都算设计的一部分，承认设计的问题有那么难嘛？
何况设计有问题不代表产品没价值，git 的流行已经证明了其成功，不需要尬吹 git cli 的设计有多伟光正。

[git00ll]

自己会用 git 决定挺爽的，团队里有不会用的，和他们配合才是心累

[gengchun]

我只是问一下，假如 stage 和 index 是一样的话，那么 stage number 是什么意思？

我的一直是理解成，index 只是说 .git/index 这个文件吧。然后 stage 指提 stage number 位，cached 就是个动词。

[victorbian]

一直只用 Windows 的人，刚开始用 Linux 哪哪觉得变扭，甚至觉得 CLI 完全多余，GUI 它不香吗？
一直用网盘同步的人，刚开始接触 Git 也会觉得变扭，什么暂存区，什么 HEAD ，图形界面、自动同步、鼠标点点的操作不就够了吗？

楼主说的第一点（某些命令功能太多，让人困惑）还有些道理，但其它观点不敢苟同，就算别的什么 CLI/GUI/UI 比现有的 Git CLI 好用，但 Git 的原理还是应当去了解吧。

我倒是觉得 Git CLI 没有很多人说的那么难用，平时常用的命令也就很少的几个。慢慢熟悉了 Git 之后，越发觉得它好用，即使是自己测试用的临时代码工程也往往会用 Git 来管理，还会主动去了解子模块等这些“不接地气”的功能。借助一些 GUI 来做 conflict resolve 或者代码行级别的提交确实挺实用的，但用的最多的其实还是亲手在命令行去敲一些命令。push/pull 、stash 、checkout 、merge/rebase 、restore 、add 、commit 、tag 、log 、show... 这些命令用习惯了很自然高效，结合不同的参数也特别灵活，GUI 往往简化了其中某些操作，却让灵活性更差了。这就像你用习惯了 Linux ，再转到 Windows 时肯定也希望有个 terminal ，而不是喷 CLI 设计太烂，或者使用 CLI 就是装逼。

Stackoverflow 投票前五的有三个是关于 Git ，这只是说明 Git 的流行。就好比你很少在上面看到关于 Windows 的操作疑问，但关于 Linux 的问题却是一大堆，这并不能说明 Linux 设计烂、不好用。很多优秀的工具是需要学习成本的，尤其是专业工具。

看到评论里很多人说 Git CLI 多么复杂难用，GUI 多么牛逼好用。现实是很多人（至少我遇到的大部分同事）都对 Git 缺乏足够的认知，觉得就像一个网盘一样把文件都加进去不久行了嘛，整这么复杂的操作干什么？然后就是把各种超大二进制文件往仓库里塞（还责怪 Git 管不好二进制文件），把自己的临时文件和临时修改加入提交，冲突的时候乱删别人的代码...

[xuanbg]

再造 git 没必要，但造个新的 cli 轮子还是可以的，只要它简单好用。