有多少人完全使用命令行管理 git 得

看了楼上的争论 得出一个结论:越傻瓜越有人喜欢 为啥呢因为学习成本
但是用了很久 并且理解和用过大部分 git 功能的人觉得 cutomization 是真的爽
而有一些之所以用 gui 呢 大部分是因为有些场景你不太可能接触到 转而求其次

@kiwi95 tmux 本来就可以算一个图形化的工具。
我在几年前的讨论里就说过了，很多人魔怔地反对 GUI ，但却自己用着和 GUI 差不多的东西，比如 tig ，比如 vim/emacs ，比如 tmux 。所以我上面说了，真当字符画出来的窗口不算窗口啊。

至于「 cli 用不明白就觉得 cli 做不了吗」我可没有这么说过哦？你是不是有点魔怔为了反对而替我发表观点了？
我自始至终说的都是 GUI 在做很多操作的时候可以省下时间，我什么时候说过 CLI 做不了了？特别是我第一句话就是 GUI 下层还是会调用命令行，你都选择性不看的是吗。

抛开事实不谈，你说得还挺好的。

gui 比命令行难用

「命令行」工具与「图形化」工具对比：

@Chad0000 #99
你那同事根本就不会用 git ，他凭什么代表使用命令行的人？

谁爱用什么就用什么，没有谁就比谁优秀牛逼。我之所以回复这个帖子，只是表明我是纯命令行的，以及我是怎么用的，不是要和谁争什么 gui 好还是 cli 好。

@msg7086 #95
你与我在用 gui ，那我就是用 gui 好了。
我为什么用命令行了，就不能用 nvim 了？

我是完全使用命令的 基本使用别名

我都是使用 git 命令

一直用 fork 。就是个工具而已，为啥非要知道具体原理

从接触 git 的第一天起就一直用的命令行，从来没用过 GUI 的 git ，一直没遇到任何问题

@msg7086

tmux 不是 gui 而是 tui 基本上终端的实现多半都是用 ncurses 这个 tui library 而 tui 全名为 Text-based user interface 是字符没错

https://en.m.wikipedia.org/wiki/Ncurses

话说为啥我觉得 fork 操作起来比 sourcetree 顺畅一些，sourcetree 总给我一种操作延时的感觉。。

回应一下 其实楼主爱用什么就用什么

@Chad0000

错 gui 是有学习成本的 尤其越複杂的应用越是如此
有些选项你甚至不能一眼看出做什么 个别应用介面逻辑还非常不同
而命令行已经有规范 原始和直觉 当然不习惯就不是直觉 但熟悉的人来讲就是控制操作流程与自动化的好工具

merge 不用 GUI 很难啊。cherry pick 之类的，使用 gui 选择也很方便,其它的使用命令行更好，有即时反馈，有进度提醒。

@msg7086 啊对对对，你说的对。从事实上说，你说的挺对，字符画的是 gui 。

很多人讲一堆什么工作流 但你工作流全被工具限制了
命令行算是比较灵活性高的 同时还是有限制 可以整齐又灵活完成目标

只会 cli 。。。

@msg7086 是的，它是运行在命令行终端的 gui 程序。

从上班第一天开始，老大就是强制我用 git 命令行。
我也保留了这个习惯，觉得还不错，对我来说比 GUI 效率高，准确。
常用的命令
`git status`
`git add -p` 加-p 使用，分阶段提交
`git show` 检查 commit 内容
其它的没什么特殊的，用到什么使用什么。 推荐看看文档：[Pro Git book]( https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)

没安装过 git 的 GUI ，一直都是手打命令
解决冲突的时候用一下 vscode 的 gitlens

8 年命令行，有不少人推荐 GUI ，但试用过后都放弃了，现在除了用 gitk 和 git citool 其他都是命令行操作。

@james122333 #111 我只是想说 TUI 本质上和 GUI 就是一个东西。功能上，使用逻辑上，都类似，只因一个用 ncurses 生成窗口、菜单、状态栏，处理键盘鼠标事件，而另一个用 GTK/QT/Win32API 生成窗口、菜单、状态栏，处理键盘鼠标事件，而莫名其妙弄出一种鄙视链来。

为啥用 Windows 没有人感觉电脑不是自己掌控的....

8 年全命令行用户

@msg7086 赞同这个观点，还有我觉得命令行最大的优势是统一性，而 GUI 不同工具的交互、操作、逻辑都不一样。所以在小公司我喜欢用命令行，大厂就用 GUI 。

@james122333 #114
我使用 sourcetree 十来年了，我没有学过 git 命令行也没有学过 sourcetree 这个软件。一切都是自然而然的。这只是一个工具而已，不需要刻意学习已经满足使了。

。。。
我发现我错了。我以为大家都是 Git Bash 的，没想到大家都是 Git GUI 。

一直都用命令行。特别是，debug + debug + debug 时，向上（ PgUp ）特别好用，不需要再另外动几次鼠标。GitHub Actions 流水线测试出错时，方便修改及提交。

12 年的时候开始用的 gitBash ，纯命令行的，刚开始学的时候很痛苦，不过熟了就好了。。
做游戏开发了，小公司统一用 svn 。
现在又用回 git 了，用的 fork ，我感觉这工具特别棒

用不习惯 gui

7 年程序员 只会 git clone/pull 其他都交给 source tree

沒用過 git gui

用不上

smartgit

基本上只使用命令行，但是在使用 diff 等功能时靠的是编辑器支持

@msg7086

你说的是使用者交互 而不是图型化 两者都是 User Interface 当然都是使用者交户 只是两者实现天差地远
终端显示都是按行显示的 gui 没有不好但这东西毕竟不适合方便组建简单应用 而不像 ncurses 其实你用 shell 都可以写类似的东西出来 其它语言也可 限制不大 gui 限制很多 也有其它缺点 至于鄙视链只是个人行为 但给我选我选 tui 方便自定义

人不能一辈子活在自己装的 b 里，用命令行并不是目的本身。

你 git branch 看看有哪些 branch ，然后再 git checkout + 你自己手敲的 branch 名字（而且还有可能敲错），这一大堆 b 事儿对于 gui 来说就是点一下鼠标的事情，但凡正常人都会去用 gui 。

@Chad0000

这前提是你先前早就熟悉其它版控工具才能如此自然 否则都是需要学习成本的 而且 git 都不是过于複杂的应用 与其它图型化大型工具相差很大

@cheny4work

命令行不是只有这种最原始的方式 你可以写脚本
使用也就是敲敲键盘选择而已 也可以用 vi 类的
我有干过类似的事情 但是是在公司 也不会傻傻手动输入资料

@james122333 你先去看看这楼的楼主问的是什么吧

@cheny4work

楼主所知道的命令行与娴熟的人是不同的
命令行不是只有手动 自动非常多
当然楼主这种都是钓鱼行为 想藉由贬损与对喷得知讯息

magit

只用命令行，解决冲突也只是用 vim 打开文件编辑一下而已，提交用 vim+fugitive 来选择片段，可以解决提交粒度不够细致的问题。

以前一直用命令行，现在基本上不用。
关于命令行和 GUI 的区别，曾经有个大神和我说，命令行的优点是方便脚本自动化和重放。
GUI 优点是直观和方便。

仅非 ff 的操作会依赖 GUI 修正，其余的是纯命令行。

用 gui 操作你放心吗

小孩子才做选择

人生苦短，我全都要，这两者为什么要互斥？

刚开始工作的时候因为系统不支持 TortoiseGit ，所以进行了艰难的命令学习。到现在只习惯命令。当然也感谢公司很早引入 git ，那个时候很多公司还在用 SVN 、VSS 之类的工具。

Gitfork 吧，命令行用的不溜还是用 GUI 比较好，不然提交了啥都不知道

oh-my-zsh 自带 git 的快捷指令，比如 gco 等于 git checkout ，gmsg 等于 git commit -m ，再加上自带的显示当前 git 分支的功能，用来操作 git 很便捷。

图形工具我只用来对比差异/解决冲突，还有像 IDEA 系的 IDE 有选行提交的功能。

那必然是 Sourcetree

主要不需要手抽出来拿鼠标，一直都是命令，有些使用频率低的命令可能记不清楚了，就查 API

idea 做合并，特别好用。其他的直接用命令，还有啥更好的办法么

git 就是最典型的 GUI 未必比命令行好用的例子，原因就是 git 解决的问题本身就不简单。

diff 用的 gui(idea 的以及仿照它实现的 gui 的 diff)主要这种左右对比方式很直观，其他都是命令行

GUI 本质上只是帮你去敲 git 命令的某一套交互方案

可能换一个工具就看不懂了，也很难把一套 GUI 的操作逻辑写成文档输出给团队

git reset origin/$(git_current_branch) --hard

git commit -v -a --no-edit --amend

都是高频且很实用的命令 配合 oh my zsh 可以简化为

groh

gcan!

就这 4 、5 个字母的输入

在 GUI 上点来点去要搞半天，有时候还要去 GUI 里搜索分支，然后发现分支不在本地，再去远程分支里找找到输入框搜索到分支，再去搜索找到对应的 commit 然后再点点点

太墨迹了，天下武功唯快不破。

这几个破命令的学习成本可能只有一天，但可以让你在整个职业生涯里受益。

说白了大部分只会 GUI 不会命令行的人（包括我之前也用了很多年的 GUI 根本不懂 git 命令），本身的问题不在于不会命令行。

而在于不愿意去接受有一定学习成本的东西，这种喜欢待在舒适区的习惯对于搞技术的人来说是很致命的。

从身边统计学来看，熟练使用命令行 、linux 、vim 的都是同一类人，而且一般都是比较极客的程序员。

据我观察 这些人普遍来说在编码能力的造诣上也要比只习惯界面操作的程序员高的多

造成习惯操作 GUI 或 习惯使用命令这种差异的本质原因可能本身就是一种能力的区别。

对于一个学习、记忆能力更强的人来说，记忆命令、单词、API 方法名 可能是一件很容易做到的事情。

越容易做到也就越容易在这件事情上获得正反馈。

就像学霸数学比学渣好，看起来是因为学霸更努力，学渣不努力。

实际上是因为同样一件事情，对不同的人的难度不一样，学霸一学就会 努力就成为了快乐的事情。

而学渣会越学越痛苦陷入负面反馈。

@Chad0000 支持+1
是的，我使用 GUI 的很重要一部分功能是查看修改的代码，相当于做一次小的 codereview ，看看是不是这些修改可以分成多个 commit ，看看是不是有不小心改动的错误代码，有没有临时的测试代码

命令跟 idea 自带的 git 管理工具都用，没有非要只用这个或者只用那个，结合着用效率更高

我最开始命令行，后来有了 gui ，就转 gui 了

纯命令行，merge 也是人肉

一些图形化界面太智能了，谁知道它们底层的行为是怎么样的？用命令行的话才不会产生任何操作上的歧义。

操作主要用命令行，查看和检查历史问题的时候会用各种 gui 。

zsh 无敌。
gaa ，gcmsg ，gp ，完事儿

装个 gui 看分支、log 、diff 以及解决冲突的时候用（涉及修改文件），比较直观。真正进行操作还是习惯用 cli （纯粹 git 本身功能的）。

最简单的，切个分支用 gui 都要点好几下，鼠标移来移去效率也太低了。特别是比如修改之前某条提交记录时间、追加内容这种参数比较多的操作，用命令行知道怎么写，gui 还要找半天不知道是不是这个按钮。

不过核心和这些都无关，主要还是对 git 命令的理解。理解了 git 那些常见命令的用法才是核心，不然自己都不知道自己干了啥，gui 又干了啥。

GUI 用过最多是 sourcetree ，其次目前主要是提交代码所以用的命令很少。记住的也就十来个左右。

哈哈搭配使用，一般提交看记录、合代码撒的，直接 GUI 搞定，，不过回滚我还是靠命令，自己知根知底

用 `git stash [pop]` 或者 `git clone` 时才用命令

不会用命令，都是 jetbrains IDE 里自带的窗口操作。

GUI 用着出错几率更低，就像有的人习惯用 VIM 编程，然后配置了一堆插件，最终的效果就是在命令行实现了一个简陋版本的 VsCode ，然后还没有 VSCode 流畅

我一直是用的命令行

什么都用，一般情况用命令行，命令行整不会了就用 gui 。jetbrains 的 gui 最好用，然后也就 vscode 了

能学习一下 cli 怎么提交一个文件内的部分变更吗？一直不知道该怎么操作，所以用的 gui

习惯了就好了，要啥经验

@msg7086 你这种才是魔怔地认为所有人都应该觉得 GUI 好。

各人的需求不同，有人觉得 GUI 好，有人觉得 CLI 好才是正常的。

tmux/vim 这种叫 TUI ，跟 GUI 最大的区别在于，可以在 SSH 里直接用。

开头用命令行, 后来很多年一直用 sourcetree, 不为难自己. 管理的子项目太多了

只用 cli ，因为 gui 会有误操作同时我不知道他到底做了什么

git add .
git commit -m "xxx"
git push origin main

一把梭.

混着用，毕竟很多操作还得是命令行，但我不排斥 gui ，win 下我一般用 sourceGit+命令行+vscode 插件（ blame+graph ），服务器都是 linux 所以我就是命令行+tig

基本都是 Sourcetree

没怎么用过 gui ，不太了解 gui 的优势，所以一直使用命令行

由于一开始学习使用的就是 git ，对 git 也比较熟悉，所以到目前为止基本都是在命令行下使用。

除了 提交 或者 合并，会使用 idea 里面的插件（方便选择提交内容）

对于 gui 的其他功能，每次使用时还要理解字面意思是啥，反而增加成本，所以就一直继续用 命令行了。

毕竟每个 gui 的字面意思都有可能不同，操作逻辑也可能不同，但最终使用的命令行是不会变的。

日常用 github for desktop 拉取、提交、建分支。

用命令，不怎么想学软件的使用了，有问题直接 help 就够了。

@ychost 666

一个人的项目.命令行当然快了..永远只有一个分支
遇到傻逼队友.只有 sourcetree 好解决冲突.好看哪个傻逼提交一个大文件.避免我去合并它.
可能命令行高大上吧..那些人.永远说不动..
sourcetree 子项目 代码自动拉去 大文件提示..快速切换分支..快速创建 gitflow 流程分支.等等.

除了 diff ，其他都用命令行

日常操作用全家桶界面，特殊问题敲命令

@MrUser #36 +1 ，我也这样，然后 fork 查看某个文件的版本记录也比较方便

习惯了 GUI 了，效率很高。长期绑定在 JB 家的 IDE 里面，很习惯了

一般用 gui 也不会用复杂功能，那些都用命令行了

alias gs="git status"

快捷

@chaleaochexist #66 https://github.com/jonas/tig 这个好用

我，而且 gui 或者 ide 自带的我用不惯。

除了看 diff 和 log 用 vscode 的界面，其他都是命令行，因为我不会用 gui

不知道 gui 的用户怎么解决 gitlab 上的冲突，尤其是多个 remote 仓库的冲突，我不确定 gui 能非常清楚的展示并且你能清楚的明确知道如何合并。
比如 revert rebase reset cherry-pick 这种操作，以及 rebase -i 这种多次请求合并这种，我也没用过很多 gui ，我不清楚他真的能展现的很好吗，我之前用过一个 gitk 什么的 一个小章鱼的图标，那个看起来不错，后来收费了，主要还是用它看 diff 。。。

@cheny4work 前面都同意，最后一句“但凡正常人都会去用 gui”，我觉得措辞不太妥当

偶尔处理问题时会使用命令行，绝大部分时间使用 gui （ 95%+）

果不其然，开始争论 GUI 跟 CLI 了...
回归正题，做好常用命令的 alias ，比如 gc=git commit ，gs=git status ，gd=git diff ，gco=git checkout ，gb=git branch 之类的。