git 操作命令行比界面有哪些优势呢？

命令

操作

重复

git

119 条回复 • 2022-03-19 22:31:01 +08:00

1 2

❮

❯

1

aababc

2022-01-14 15:20:43 +08:00

简单，方便，直观，可以满足大部分的需求，输入一堆的命令，GUI 只需要点点手指。但是高级功能命令行还是很方便的。

2

66beta

2022-01-14 15:21:33 +08:00

2

经常使用，熟练之后可以应付面试

3

lujiaosama

2022-01-14 15:22:49 +08:00

高级功能还是要上命令行. 比如说整个 cherypick 啥的, gui 我操作不来.

4

qiany

2022-01-14 15:25:44 +08:00

1

可以复制粘贴

5

momocraft

2022-01-14 15:26:26 +08:00

1

history 知道自己做了什么可重放

6

richangfan

2022-01-14 15:27:17 +08:00

可以在服务器里面操作

7

nine

2022-01-14 15:28:37 +08:00

没啥优势

8

TomatoYuyuko

2022-01-14 15:28:46 +08:00

2

其实也不互斥啊，工具而已怎么舒服怎么来。就好比那种电动螺丝刀比手动的效率高多了，遇到犄角旮旯再手拧也不耽误。工具是给人用的，不能削足适履。（面试除外）

9

MacDows

2022-01-14 15:28:57 +08:00 via Android

可以写个脚本

10

newmlp

2022-01-14 15:35:55 +08:00

逼格高

11

fengfuliu

2022-01-14 15:36:46 +08:00

每次提交的时候盲操作键盘敲的一气呵成有一种莫名的快感

12

mitsuizzz

2022-01-14 15:39:06 +08:00

1

能直观的知道做了什么，工具什么的一通按，怕误操作了某些东西，毕竟协同的，少出乱子

13

hello158

2022-01-14 15:39:09 +08:00

1

能少学一样就少学一样。我都已经会了命令了，还要学习界面怎么操作，我不想学了。输命令还很快。

14

wudicgi

2022-01-14 15:40:34 +08:00

如果不是写脚本要用的话，没啥优势

15

LotusChuan

2022-01-14 15:43:02 +08:00

2

我命令行操作 git 比图形化界面快。此外 git 在命令行里面整个生态都好很多，对它自身而言有功能比如内置 trigger 可以实现自动化，对其他工具而言有像是 vim 的 fzf 插件可以实现在整个 repo 里面模糊查询快速移动，比图形化界面快很多。

但是这些都建立在你整套开发大部分在命令行里面的前提上，要是本身就是全套图形化界面，那为了用个 git 特意开个终端挺多余的。

16

pkookp8

2022-01-14 15:46:28 +08:00 via Android

写 shell 可以用

17

SSang

2022-01-14 15:47:06 +08:00

3

对于很多不愿意使用 git 图形界面的人来说，理由就是，我无法知道当我点下这个按钮后到底发生了什么。

黑盒对基础操作来说是十分友好的，但毕竟是一层封装，无法做到随心所欲。

18

anonym233

2022-01-14 15:50:10 +08:00

正常流程使用 GUI 或者命令行都没差。于我而言，我用命令行，只有看历史提交的时候用 GUI 工具。因为用命令行做一些操作会比较方便，比如 cherry-pick 某个 commit ，checkout 某个 branch 的某些文件，或者整理分支 reset --soft ，合并最新代码 rebase origin/master 等

19

SSang

2022-01-14 15:50:19 +08:00

界面实际上就是客制化，只是客制化并不一定适应所有人。

当你使用 shell 脚本时候，其实你在做的事情，和写图形化界面的人做的事情并无两样，只是出发点不同，但目的是一样的。你不愿意使用工具，应该只是这个工具刚好不符合你的需求

20

raptor

2022-01-14 15:51:22 +08:00

习惯了，毕竟很多事情都在命令行里操作，顺便就一起做了

21

agagega

2022-01-14 15:54:22 +08:00

Git 自己的命令行都分上层命令和底层命令，上层命令是用脚本对底层命令的封装。GUI 就是把上层命令再封装了一层，happy path 可能没毛病，但遇到点问题可能就抽象泄漏了

22

yukiww233

2022-01-14 15:56:00 +08:00

emmm 用 idea 自带的 gui, cherry-pick 不是一键完成么

23

Cloutain

2022-01-14 16:00:51 +08:00

我只会用乌龟 GUI 。。。

24

ZeroClover

2022-01-14 16:03:39 +08:00

其实可以试试 Sublime Merge ，CLI 思想的 GUI 操作。

对于刚学习 git CLI 而言还是比较友好的。

25

orzorzorzorz

2022-01-14 16:03:51 +08:00

1

ui 妹子来找我对需求的时候，我会敲命令来显示我的手速，用以表示自己的交配权尚未得到保障。就一个人的时候，简单的命令就点点点，rebase 这种需要保证提交记录干净的，那还是会敲一敲让自己安心的。

26

0o0O0o0O0o

2022-01-14 16:16:32 +08:00 via iPhone

https://github.com/microsoft/vscode/issues/32405

27

kidonng

2022-01-14 16:22:24 +08:00 via Android

git -C
git --git-dir
GUI 如何优雅替代以上参数，急，在线等🐶

28

unco020511

2022-01-14 16:26:19 +08:00

我比较菜,还是习惯 gui

29

justwe7

2022-01-14 16:30:06 +08:00

gaa
gcsm
ggpush
配合 zsh-autosuggestions ，提交代码不要太爽

30

james2013

2022-01-14 16:32:18 +08:00

提升了打字速度

31

340244120w

2022-01-14 16:34:45 +08:00

@kidonng #27 不太会命令，不过需求是啥

32

andrewpsy

2022-01-14 16:39:53 +08:00

1

家里各种轴的键盘十把左右，必须要多打字才对得起它们。

33

lujiaosama

2022-01-14 16:41:29 +08:00

@justwe7 你这是自定义的快捷指令么? 我之前很多指令这么搞的, 换部电脑就有时得卡顿下想想原来的命令怎么回事.感觉不是特别通用. 还有在 win 上没有 zsh 我都整不会了.

34

Maxxxxyu

2022-01-14 16:55:35 +08:00

需要复杂操作的用指令，但就日常的 commit ，push ，pull 啥的，gui 界面方便很多

35

chengyiqun

2022-01-14 17:01:49 +08:00

idea 自带的 gui 够用了, 如果有其他需求, 就用命令行, 合适就行. 总之就是不同的操作, 用 gui 和用命令行都有省事的地方, 哪个省事用哪个.

36

GalaDOS

2022-01-14 17:12:15 +08:00

用的编辑器比较多，gui 很多套，不想一个个去熟悉，命令行统一解决比较省心

37

ksc010

2022-01-14 17:15:41 +08:00

看你使用场景了，感觉用啥舒服省事就用那个
我平时提交的时候就用 gui 审查代码改动了啥感觉很方便
一些自动话的脚本就用命令行

38

leeyuzhe

2022-01-14 17:18:23 +08:00

jb 家用 gui ，然后 vscode 用命令行，因为 ui 是在太难用了

39

wonderfulcxm

2022-01-14 17:20:37 +08:00 via iPhone

在服务器没有 UI 操作的时候

40

tuwulin365

2022-01-14 17:25:46 +08:00

命令行的优势就是不需要安装 gui 工具

41

BeautifulSoap

2022-01-14 17:27:32 +08:00

11

git 只用命令行地非常多人早就已经把下面这一把梭练到炉火纯青了

git add *
git commit -m "message"
git push

每次 review 别人的代码，看到提交上一堆.DS_Store ，ide 临时文件夹，测试用的账号密码之类的猜都不用猜，那人 100%是只用 git 命令行而且拒绝使用 GUI 的主

说真的无论是命令行也好用 GUI 也好，最重要的是正确安全地完成工作。你只用命令行也行，但这这种用了命令行为了方便偷懒地做法，真的没什么资格去谈“命令行很酷”“GUI 我不知道做了什么，命令行我放心”之类的

42

industryhive

2022-01-14 17:34:34 +08:00

没有优势，用 IDEA 的 GUI 界面操作 git 非常方便，我看别人用 VS Code 操作 git 都用命令行，那个效率慢的让我捉急。。

43

gadfly3173

2022-01-14 17:38:45 +08:00

@kidonng #27 在 gui 里好像没什么必要跨工作目录去执行 git——切一下 tab 不比你打路径快？

44

freedomSky

2022-01-14 17:50:01 +08:00

据说有人是因为 magit 还保留着 emacs 的

45

tuutoo

2022-01-14 17:53:33 +08:00 via Android

gui 总的来说是方便
但是只会 gui 不知道后面执行的命令也不好
切到 linux 下没 gui 就活不了了

46

liubaicai

2022-01-14 18:02:35 +08:00

gui 也就看 history 和 branch 方便，其他还好

47

mxT52CRuqR6o5

2022-01-14 18:05:54 +08:00

gui 我可以方便的选择性的提交某些文件，甚至于只提交一个文件中的部分修改
命令行选择性提交部分文件应该没 gui 方便吧，只提交一个文件中的部分修改我没深入了解过不知道要怎么用命令行操作（就算有能力操作的话操作起来应该也不容易吧）

48

akira

2022-01-14 18:25:10 +08:00

gui 是对命令的封装
命令是对代码的封装
本质上其实都一样

49

placeholder

2022-01-14 18:29:11 +08:00

git clone --recursive

git add

git commit

git push

目前为止就用到了四条命令实在没必要开 GUI

50

chi1st

2022-01-14 18:40:32 +08:00

逼格

51

18000rpm

2022-01-14 18:41:27 +08:00 via Android

1

unix 工具链。有用的是 grep, awk, cut, sort, while, xargs 这些，否则为什么要装 Linux 买 macOS 。

52

nicebird

2022-01-14 18:53:11 +08:00

简单啊，大部分就一些简单指令

53

yongSir

2022-01-14 18:57:12 +08:00

对我来说
1 最大的好处是不用下客户端，讲真，我在学校喜欢用 sourceTree ，知道它某一天某个版本要登陆注册，然后还要挂梯子注册，当时实验室的网很难搞，我就从此告别客户端了，不过想 diff 还是要借 vscode ，毕竟 vim diff 我看着不方便
2 就是命令行你不用学习任何新的按钮 /快捷键之类的，永远没有客户端更新 /更换，快捷键 /按钮更换的学习成本
3 第三是用不上，通常开发中 git 操作就那个几个，命令行完全足够

综合对我而言，够用就没必要添麻烦你..... 勿喷

54

retrocode

2022-01-14 19:03:59 +08:00

小乌龟够我用了 GUI 没啥需求

55

shayuvpn0001

2022-01-14 19:36:20 +08:00

@retrocode 小乌龟不是 GUI ？黑人问号.jpg

56

litmxs

2022-01-14 19:43:44 +08:00 via Android

简单的提交回退合并都直接用 ide 自带的，复杂的操作用命令行

57

november

2022-01-14 19:46:38 +08:00

@shayuvpn0001 windows 的小乌龟有提供 bash 终端，可以输入命令行。

58

retrocode

2022-01-14 19:49:41 +08:00

@shayuvpn0001 #55 好吧,可能我对 GUI 的定义有点严格了.我的锅.我之前一直把小乌龟定位在插件类别...右键提交什么的

59

shayuvpn0001

2022-01-14 20:39:33 +08:00

@november 你真是优秀

60

ngn999

2022-01-14 20:52:10 +08:00

比 gui 快.
另外是跨平台能用的. gui 的你换一个 app 就要重新学习.

61

24bit

2022-01-14 21:06:47 +08:00

cli + magit ，gui 主要在解决冲突的时候用

62

leafre

2022-01-14 22:03:58 +08:00

@BeautifulSoap 太对了，有些人只是为了用命令行而用命令行

63

darkengine

2022-01-14 22:20:57 +08:00

在公司打杂，需要给多种语言的项目提代码，每个 IDE 的 git GUI 操作方式都不一样，还是命令行一把梭来得快。

64

nobody1234

2022-01-14 22:23:53 +08:00 via iPhone

@mxT52CRuqR6o5 一个文件的部分修改回滚或提交这点的确是 GUI 的优势

65

gengchun

2022-01-14 22:43:21 +08:00

@BeautifulSoap

用 GUI 一样会有 .DS_Store 这些。这个只和有没有正确添加 .gitignore 有关系。如果出现 ide 临时文件夹，那是 IDE .gitginore 生成的策略有问题。

真要避免，最好是项目新建时，脚手架模板自带，再加上服务端提交限制。如果是代码是你负责，你应该做这些事情。当然，也可以甩给 devops 。但没法甩给 git 界面。

66

szzhiyang

2022-01-14 22:48:43 +08:00

Git 的命令行就是为其 GUI 而生的。

67

szzhiyang

2022-01-14 22:51:21 +08:00

命令行与 GUI 的关系相当于 API 和 App 的关系。

68

gengchun

2022-01-14 23:01:27 +08:00

@mxT52CRuqR6o5 部分提交一般是编辑器的 git 扩展 /插件的事情。当然，git 的 --interactive/--patch 参数是反过来，你可以把编辑器看成 git 的插件。这完全取决于你的视角。

当然，这个时候，你可以把 core.editor 设成任何一个 GUI 。

69

ClericPy

2022-01-14 23:38:56 +08:00

之前有个前辈是这么回答的: 我的系统没有图形界面

70

BeautifulSoap

2022-01-14 23:46:57 +08:00 via Android

2

@gengchun 你这用来狡辩还不承认的说辞和我之前遇到的实习生如出一辙

问题在于有没有配置.gitignore 吗？问题明明在于用了命令行但却嫌麻烦偷懒，所以养成了无脑 git add * 的坏习惯还不改。
你可以配置自动忽略.DS_Store 但你没法忽略测试用的帐号密码，没法忽略临时改改但不想提交的变更？很多次 review 别人代码都遇到类似修个 bug 临时改了 log 类用于调试，然后修完 bug 后把忘了这茬把 log 类文件也给提交上来的了。这种情形只有写代码的人每次提交前人工确认一遍才能发现和预防，而 git add *一把梭的人大概率会出这种问题

话题回到 GUI ，你用过 GUI 的话应该知道几乎所有 GUI 都会以非常易读的方式展示修改的文件一览，每次提交前都会强制你手动勾选要提交的文件。这就相当于强制你确认文件变动了。当然真不想慢慢选的人还是会出错的，但出错概率至少比直接 add *要小很多

71

gengchun

2022-01-15 00:31:25 +08:00

@BeautifulSoap 你这肚量也是可以了。还跟一个实习生计较，跟个坛子里遇到的不相干的人也计较。你拿多少钱，人家拿多少钱？

我这么说，当然是因为我遇到过这样的事情。我不光遇到过，我还查找过的原因，可惜都是通过 GUI 提交的。陈述一下经历，这就成“狡辩”了？我就混个坛子，又不是来认爹的。就算你年入一个小目标，也不至于这么膨胀吧？

我的原则是拿钱多的，活多干点，担的责任大点。若我拿钱少，别人爱干嘛干嘛。我也不想管。你要通过训话管理下属，那是你的事情。但我提醒你，没事火气别这么大，多为建设和谐社会做贡献。毕竟只是工地，不是黑社会。

72

Chwaiz

2022-01-15 00:34:40 +08:00

实际经历:
在有大量改动时,GUI 会卡死,用命令行几秒钟就重置了,很快
个人习惯平时还是用 GUI 多,必要时用命令行

73

gengchun

2022-01-15 00:36:29 +08:00

@BeautifulSoap 另外，再提一句，我个人是不赞同在自己本地开发机上部署调试，至少较大规模的项目不应该这么做。可能的话尽量在测试环境做这些事情。

我确实没有遇到过测试环境账号和运行日志被提交上来的。因为测试环境，开发机根本就访问不了。开发机上的代码就算编译了也根本跑不起来。

74

msg7086

2022-01-15 01:18:20 +08:00

@gengchun 问题在于你说的：
> 这个只和有没有正确添加 .gitignore 有关系。
楼上说你是狡辩，我觉得这不是狡辩，这是瞎基尔扯淡。

构建提交的时候应该把要提交的代码包括在提交里。不管文件有没有在 ignore 里，把不应该提交的更改提交上来本身就是错误。确实，用 GUI 也有人瞎基尔提交，只不过 GUI 更直观，容易把事情做对。

实习生犯错很正常，因为他还在学习过程中，事情做错了，被人指出来，改正就行了。最可怕的是理直气壮地把错误归结到别人身上。乱提交文件怪 gitignore ，下次是不是还要怪同事没有把着你的手？运维要是把服务器搞坏了是不是还要怪 IT 没把键盘上的回车键抠掉？不愿意学习改正，那就一辈子拿实习生工资好了。

至少我很庆幸我们组里没有这种犯错还要甩锅的人。

75

msg7086

2022-01-15 01:30:53 +08:00

我拿我常用的 SmartGit 来试试看你说的操作。

第 1 条附言
比如这种组合操作：git checkout -b readytomerge && git reset `git rev-parse master` && git add . && git commit -m 'xxx 功能开发' && git checkout master && git pull && git merge readytomerge

这是在做 squash merge 吗？
1.签出 master 并 pull 。
2.右键 readytomerge 分支，点 merge ，选 merge 到 working tree 。
3.修改提交信息，选中 squash ，点 commit 。

第 2 条附言
比如新建回滚分支：git checkout master && git pull && git branch -D rollback && git checkout -b rollback && git push origin --delete rollback && git push -u origin rollback

1.签出 master 并 pull 。
2.右键 HEAD ，添加分支 rollback 。（如果已经有 rollback 会提示覆盖。）
3.右键 rollback ，push 。（如果已经有 origin/rollback 会提示 force push 。）

==========

从操作数量上来说，GUI 确实比运行一个命令要多。但是如果在合并过程中产生冲突更改，GUI 中解决更方便。命令行组合操作的大前提是中途不会出现错误（冲突等）。

76

xiadong1994

2022-01-15 01:33:47 +08:00 via iPhone

1. 更换机器没有学习成本。
2. 我的大多数机器都是 ssh 上去的，没有 GUI 。
3. 有的比较复杂的操作我不知道 GUI 怎么用，比如查找某个分支里所有不被某两个 tag 包含的 commit 。
4. CLI 可以在你想要自动化的时候非常方便的和其他命令和脚本结合起来。
5. CLI 的行为是稳定可控的。

77

msg7086

2022-01-15 01:33:53 +08:00

另外，命令行的劣势在于命令是固定的。如果你要新建一个回滚分支 rollback2 ，那你的命令就不能用了。同理，如果你要提交的功能分支名叫 feature-2 ，你的命令也就不能用了。在日常开发中，同时做多个功能的开发、合并到多个不同主线分支，是很常见的场景。（ bugfix 合并到 release 再 cherrypick 到 master ，feature 合并到 develop ，等等。）

78

BeautifulSoap

2022-01-15 01:48:41 +08:00 via Android

@gengchun 我平时工作可是非常大度的，因为大部分人都是正常人，被指出来问题后至少都会接受，也不会去找各种原因来为自己狡辩。提交了不该提交的东西做错事了就是做错了，下次多注意就行，我也不会再多说什么。

而那位实习生我印象深刻就是因为他不光不反思自己 add *还不确认提交内容这件事的危险性和错误性，被指出来后死鸭子嘴硬全甩锅到.gitignore 上。和你的发言如出一辙，所以对你说话我毫不客气，也不认为需要客气，这反倒被你认为我平时工作就这样欺压实习生的态度，呵呵

至于环境什么的都没关系，只要继续 add *一把梭，无论你用什么环境怎么配置，今后依旧非常大概率会把不该提交的更改给提交上来

79

3dwelcome

2022-01-15 01:50:56 +08:00

用 GUI 能合理减少心智负担，把脑容量留下来多记点别的，命令参数有什么好记的。

我自己喜欢找命令行的常用公式，弄到批处理或者简单命令行程序，最后用 GUI 右键菜单给关联起来。

80

zzxgz

2022-01-15 02:45:38 +08:00

在 github desktop 里面我不知道应该怎样为一个 commit 签名，所以我就用命令行，因为它直接 -S 就可以了。

81

YuTengjing

2022-01-15 04:03:55 +08:00

没啥优势，只是够用。

82

js8510

2022-01-15 05:17:57 +08:00

所有 CLI 其实都是一个道理：更简单。

比如你要 rename 两个 var 涉及两千个文件。你修改了之后发现，其中一些不用修改，这时候你只需要
`git status | grep xxx patern | sed xxx changes` 就可以了。。

另外比如你的开发用的机器是个 server,这个很常见。。如果你要用 GUI. 你就要先有支持 remote 功能的 GIT UI. 相对复杂一些。但是如果你对 GUI 没有依赖，那你基本上上手就能工作。

83

js8510

2022-01-15 05:23:35 +08:00

我有个前苏联的程序员朋友。他年轻时候是做面向一般用户的 GUI ，帮助计算机普及。当年是很新潮的概念。他觉得现在很多程序员可以完全依赖 GUI 做开发，是他当当年怎么也无法想象的。但似乎也是个好事。尤其做前端开发，真的可以做到一年不用敲一行命令，全都拿鼠标点。

84

Chad0000

2022-01-15 05:51:18 +08:00 via iPhone

对我来说能点几下鼠标我就避免敲命令行，而且 gui 更直观，一些新知识 /功能你看到了就掌握了。

敲命令行费心智。

85

fatestigma

2022-01-15 06:21:29 +08:00

@freedomSky magit 太香了，org-mode 和 magit 让我再也无法转换阵营

86

wellsc

2022-01-15 06:50:18 +08:00 via iPhone

@BeautifulSoap 哥，难道不是 gui 才是偷懒的，gitignore 跟命令行 gui 有什么必然的联系吗

87

IgniteWhite

2022-01-15 08:42:25 +08:00

@freedomSky
@24bit
@fatestigma
fugitive 和 magit 很多功能甚至 keybinding 都是相同的，在我看来两者都是极好的

88

AllenHua

2022-01-15 08:58:05 +08:00

由于平常使用 git+markdown 的形式记录笔记、代码和生活琐事到 GitHub 等平台，所以我给自己写了一个 git add, git commit, git push 的 bat/shell 脚本。

https://github.com/hellodk34/gitpushworkflow

欢迎有需要的朋友使用。在这个项目里我认为 git 命令行的优势就体现的很明显了——可以封装脚本。另外上面有朋友提到的 git add * 之类的会添加所有文件，那事先配置好 .gitignore 不就好了么。

89

Jackeriss

2022-01-15 09:09:31 +08:00

喜欢敲键盘的用命令行，懒得敲键盘的用 GUI

90

gengchun

2022-01-15 10:06:02 +08:00

1

@BeautifulSoap 作为了一混社会的老油子，我得说，大部分人被人指出问题，没那么爽快接受的。除非对方是权威，比如说人民警察什么的，像我是从来不敢去杠人民警察的，毕竟底层人民。

这么顺风顺水，想来您就是个权威。

现在 OP 炫耀一下自己的工作流，只因为是用命令行的，就回个贴打击一下。OP 就算用了 git add . ，他执行之前，完全可以用 git status 看一下。

我说一下我这里的 .DS_STORE 本来就都是 GUI 提交上来的。你也要针尖对麦芒来一通。我对付人家人办法，现在提到的至少了改四五个地方，这是“全”甩锅到 gitignore 上吗。我把锅扣在自己头上算“甩锅”？

当然这事开发甩锅到 gitgnore 上面有什么用呢？这东西还不是开发写的？开发不检查，锅不还是开发的？那实习生就是开发，他要说是 gitignore 的事情，他这不甩锅？

你处理别人提交上来的的 .DS_STORE 是直接和别人开怼，搞不好还闹得大家都很不开心。

同样是处理别人提交上来的 .DS_STORE ，我是媳妇侍弄婆婆；你是爸爸教训儿子，这是“如出一辙”吗？

您用了这么多成语。就为了一个界面？我说脑机接口最牛逼，GUI, TUI 什么的都是渣渣。

所以，实习生这个事情在你们那里，估计是确实令人“印象深刻”。