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 的各种功能是堆出来的，可以说基本上就没有什么设计可言，这个鬼样子也是可以理解的。

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

修正下，新建并切换分支是 git checkout -b，而不是git branch。

即使用过很多次还是没记住……

这明明是先新建分支，然后再切换却在checkout上，有点太反直觉了，谢谢提醒。

git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]

[AndyAO]

还有就是 linus 本人对这个工具没有什么兴趣，因为有这个需求，但是总是拖了又拖到最后没办法才自己干，完成最初的版本，能用之后就撂下不管了，后来是社区维护的，完全是自己生长出来的。

这样自发生长出来的东西，往往在设计上就是丑陋，没有什么美感。

生物的基因也是这样啊，里面有大量的冗余的没用的内容，而且基本上不可能有任何的更改。

推倒重来，重新开始，有时候是必要的。

[gowk]

我认同，但是谁有勇气和能力再造一个 git?

[dcoder]

git cli 的用户体验确实烂得不行...

[cmdOptionKana]

github 已经自己出了 cli

[461da73c]

@AndyAO 用了几年的 git ？建议提高自己的水平，从你看书学 git 大概知道你的水平了，而不是做无脑的抨击，喷不到点上。

[imldy]

只是命令，可以再套一层吧(=_=)

[yyfearth]

同意你 L1 的观点
这个做产品和生命树类似
一开始点的技能树后来就算没用了 也会影响之后的决定

想要符合最新的需求而且追求完美 就需要重新设计
但是又要向后兼容

这样的话 其实搞一个新的 CLI 包一层就是了

[xtinput]

那你去用用 svn

[zed1018]

@461da73c 非常典型的：我学不会的就是垃圾

[balabalaguguji]

来吧，SVN 简单快乐，SVN 欢迎你 https://svnbucket.com

[AndyAO]

人类的基因方面，对生物学没有了解的人可能会不太清楚。

如果你观察胚胎的发育过程，就会发现很多人类根本就用不到的结构，是先生长出来之后然后消亡的。

也就意味着整个胚胎发育的过程就有点像重演了，生物的进化史很多已经没有必要的过程都还存在。

典型的是如果你观察胚胎的话，你会发现人类最开始的时候指头是有蹼的，发育的后期这个结构才会消失。

如果能对人类基因的代码进行大范围的重构，那么人类的整个效率会比现在要高的多的多。

[macha]

git 只是免费的里面最好用的。

[balabalaguguji]

表示挺认同楼主

[cco]

凑合能用，没那么差，也一般般，日常工作没问题，关注点主要放在代码上。

[hand515]

管它烂不烂，我把常用的命令用熟练，能解决我的问题就好了

另外，说“太烂”，给人的感觉是对别人的工作的全盘否定

[zxCoder]

git 是否是开源的，能否重新设计一套 cli 命令？

[acmore]

@AndyAO 非杠，算是根据自己了解的内容来细化和补充：
胚胎发育不完全是进化的重演，最多能算是找到一些演化的痕迹，很多演化树上的东西都不会出现在胚胎里。原因是进化很少重构，都是叠床架屋。
人类物种基因如果重构成纸面上完美的状态会迅速灭绝，因为这意味着人类基因失去了对外界（病毒，自然选择压）的任何应对窗口。当然人类基因和完美是不沾边的，有很大的改进空间。

[yolee599]

你可以自己再封装一层啊，想写成怎样就写成怎样

[ampedee]

@461da73c 看书学 git 有什么问题？难不成你能靠 git 的命令行帮助掌握 git 的原理和进阶操作？
你知道 git checkout 有多少种不同的用法么？
git 自己都承认了 checkout 的历史包袱，在新版本推出了 switch 和 restore 来替换 checkout 。

🤡🤡🤡

[makelove]

没有同感。如果你说的就是重新组织一下一些 cli 的选项名，这不能说是 git 极烂吧，照这标准 windows 不是烂出天际了

[yEhwG10ZJa83067x]

无语，你可以完全用 alias 命令设置一套你熟悉的命令不就可以解决？！

[Narcissu5]

git checkout -b 这个有什么难记的，我一次就记住了。实在记不住下个 ohmyzsh 帮你自动补完。实在不行还有一大堆 GUI 工具。

git 最优秀的地方在于分布式仓库的设计思路，分布式嘛，一定很麻烦的。如果你学了半天 git 最后的感想就是 cli 难用，那就真是如入宝山空手回了

[cyrivlclth]

如果只是这些的话，你为啥不 alias 或者包一层。。。

[FengMubai]

git checkout 承担的功能太多了, 已经再改了. 比如切换分支现在用 git switch (建议直接去和 Linus 对线

[dangyuluo]

你要知道 Git 最初版本连 commit ，stash 什么都没有，干什么都要手动修改历史树。

话说熟能生巧，这些东西应该靠的是肌肉记忆。如果实在不想打一长串命令，用 git alias

[zjsxwc]

用刀叉影响我吃满汉全席吗？

楼主的意思是由于使用了刀叉，所以满汉全席就是垃圾。

[Cbdy]

我觉得还行

[adoal]

楼主，又见楼主 ^_^

[SimonOne]

@zjsxwc #26 楼主说的是满汉全席(git)很好，但是配套的工具(git CLI)有点难用，所以工具设计(git CLI)太烂。

[charmToby]

又不是不能用 （逃

[yuuko]

用了几年 git ，常用的无非几个，git pull git push git checkout git commit git rebase git merge git tag

[zxxufo008]

一般说太烂的都是能搬出来新东西,来推翻的.可惜没在 op 身上看到这点

[zooeymango]

git alias 在官方文档的 book 里第二章就有，属于基础知识，感觉你连文档都没有扫过就来评价，这也不太好吧

[bnm965321]

git checkout -b

为什么可以说明是参数设置随意？

另外 Git 不好学的原因我觉得很大一部分是新人不熟悉源码版本控制的数据模型，不知道为什么要这么做。

[Reficul]

我是觉得 git 比 GUI 有的场景下好多了。。

总是交换着一起用

[Volekingsg]

https://stevelosh.com/blog/2013/04/git-koans/

在上面套一层套的最好的就是 magit 了吧

[guyeu]

linus 设计的时候 git 只是一套底层命令，现在的 commit 、branch 都是基于这套底层命令封装的，你也可以封装一套，跟社区对着干

[alexsunxl]

git cli 很庞大的。 这么多年，很多老的 api 一直兼容着，很难动。 不喜欢套一层就好。
git show-ref git update-ref git unpack-objects git remote 这些你都没用过吧。
git 还能通过 remote-helper 搞私有协议。非常强大的。
楼主你说这些点真的是太小太小的一部分了。

[cc666]

@461da73c 学了几年的语文，建议提高自己的语文水平，从你抨击 OP 看书学 git 大概知道你的水平了，而不是做无脑的抨击 OP ，喷不到点上。

作者没有说 git 不好，说的是 git CLI 设计有失误，具体包括子命令功能是名不副实、某些命令功能过多以及部分名词混用，作者提的几点都是实打实存在的，怎么会和你所说的"git 水平"有什么关系，只能说，你用多了，已经避坑了，但是依然掩盖不了问题存在，如 19L 所说，git 在 2.23 中引入了 git switch 和 git restore ，用以替代现在的 git checkout 。并说明了现有的软件难以更改，这是确实存在的问题，至于 git alias 和套壳，也正是解决这一问题的可行方法而已。

[Accessing]

这只是单纯的讨论设计问题，但是在很多楼层看到了饭圈味道，哪个软件合适，用哪个，没那个必要啊。那种评论有时候很吸引眼球，但是非常浅薄，没有提供任何有用的信息。

[ShuoHui]

我还以为是我学艺不精

[libook]

普通需求场景下，基本只会用到几个核心指令；
有更复杂需求的场景下，基本都会用 alias 、写脚本、工具、shell 插件。

社区驱动的开源项目往往会朝着符合社区用户的需求方向发展，git cli 发展成这个样子，对社区来说是具有必然性的。
题主觉得不合理，可能题主的需求场景和社区用户的普遍需求不一致，那么可以考虑加入社区做提案，或者自己做一个新的 cli 。

[jatsz]

基本上只用 Git CLI 原因是统一性高，而且常用的命令就那几个，如果你理解了 git 的暂存区，理解 git 其实是操作文件，那么就很容易记住那几个命名，无非就是先放到暂存区在提交。

有的时候帮同事看个东西，我被那个花里胡哨的界面搞得我都没自信做出一些操作--谁知道你一点下去发生了什么。

[shayuvpn0001]

你去看 Linux 内核，里面有更多更丑陋的东西，更多不符合设计原则的东西，但是和你说的一样，从历史发展的眼光来看，就应该是这样。

[pkoukk]

简单，用 gui ，不用 cli ，我就是这样

[felixcode]

大多数时候，批判一件事物的门槛挺低的，知道皮毛就行，肯定一件事物的门槛却比较高，因为需要了解的比较深入。

[securityCoding]

用 idea 的 git 客户端

[raptor]

所以我早年一直用 HG ，就是因为 GIT 的 CLI 设计太没逻辑，然而没办法对抗大趋势啊……

[darknoll]

那你别用不就完了吗

[RainyH2O]

其实你觉得不行，完全可以基于底层命令，设计实现一套上层 CLI 开源出来，发出来推广，不存在什么晚了的说法。
就像 Oh My Zsh 之于 Zsh 一样，实际上很多 Git 的 GUI 本身就是用的底层命令去实现那些上层的功能的。
要我说 Git 的核心只在于理解三棵树模型，CLI 再怎么设计也不可能减少理解这层的成本，而理解了这层的人也不会介意目前的 CLI 设计。

[starcraft]

难点就是 git 实际学习的时候是需要知道底层实现原理的，单单命令无法像 linux 那样，做到不深入也能做到完美的抽象。这就导致了后来的人，开始设计各种各样的指令来帮助理解，来做妥协，但我认为这实际有增加了各种奇怪的认知负担，特别是设计的人水平、理解都不一样。

[iyaozhen]

你这没喷到点子上，git cli 再烂一些都没关系

git 的问题是你要使用它就必须理解或者说接受它的一套逻辑，不是自己想当然。简单来说就是学习曲线陡峭
但你协作的需求不复杂，这陡峭的学习成本就没啥用，还不如大家都装个百度云同步代码。

关于 cli 本身，建议还是理解 git 逻辑后，用 IDE 自带的 gui 吧，很好用

[lingxi27]

show me u code

[lin07hui]

用什么 cli ，gui 它不香吗。vue 我都是用 vue ui

[ruanimal]

看了楼主发的一系列帖子，就是人菜瘾大

[hereIsChen]

推荐个学 git 的网站
learngitbranching.js.org

[huajieyu]

git 命令功能耦合度确实是过高，所以有了 git switch ，git restore 等来对 git 的功能进行解耦

[hugepizza]

git 很强大 但是 gitcli 确实烂啊

[zthxxx]

再喷一个 git merge <target> ，merge 命令的方向是 current branch merge **from** target

而正常情况的自然期望是把 current merge **into** target ，就比如提 GitHub PullRequest / GitLab MergeRequest 时就是这种自然的方向；

这导致一般人在本地 feature 分支上想同步一遍 master 分支，直接跑 git merge master ，结果把 master 分支合到 feature 分支了；

[piping]

@zthxxx git cli 的逻辑就是对分支的修改总是对当前分支进行的。 只要了解这一点，merge rebase 什么的都很好理解。 想修改哪一条 branch 就切换到那条 branch 上

[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 轮子还是可以的，只要它简单好用。

[zthxxx]

@zthxxx #59 重新换了只手画图
https://excalidraw.com/#json=aSCX4r3o8BmSb8whN3_ST,GjNYhhphSztYqEwMWUyxvQ

[abcdxe2v]

每次我搜 git 的某个功能搜出来几个互相矛盾的文章，都来看这。。。