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

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

[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 上