git CLI 设计太烂

• 主 資深大佬 : 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 不是烂出天际了

• 資深大佬 : justrand

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