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

[lingdu666]

个人理解，重复的很多操作，命令行提炼出一个命令包含多个操作 通过 && 连接，但是界面需要很多重复操作，还有其他优势吗？

[24bit]

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

[leafre]

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

[darkengine]

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

[nobody1234]

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

[gengchun]

@BeautifulSoap

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

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

[szzhiyang]

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

[szzhiyang]

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

[gengchun]

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

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

[ClericPy]

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

[BeautifulSoap]

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

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


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

[gengchun]

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

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

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

[Chwaiz]

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

[gengchun]

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

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

[msg7086]

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

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

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

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

[msg7086]

我拿我常用的 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 中解决更方便。命令行组合操作的大前提是中途不会出现错误（冲突等）。

[xiadong1994]

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

[msg7086]

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

[BeautifulSoap]

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

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

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

[3dwelcome]

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

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

[zzxgz]

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