用 Git 一定要用命令行嗎？用命令行一定高貴嗎？

01-03

曾經面試官問我github熟悉嗎，我說熟悉，他說命令熟悉嗎，我說我用的GUI（官方提供的桌面端和webstorm集成的github插件，就夠用了），他說，怎麼能用GUI，你這太不專業了，必須得用命令行啊。然後一臉嘲諷……
我覺得github只是工具，怎麼方便怎麼來，而且目前工作也沒用到太多的git複雜的命令，之前也學過，不用也都忘了些，我覺得工具方便我的開發就行，為什麼要瞧不起用界面的呢？

首先用命令行不高貴，用GUI也不low，但是這個面試官噴你確實很low

GUI有GUI的好處，通常情況下滿足你的操作需求，用起來沒有問題。

但是命令行有命令行的好處，有些命令GUI很難給你提供就不說了，命令行有些獨特的好處：

一是錯誤提示非常詳細，詳細到你知道錯哪了，正確的用法是什麼，一來二去很快就能熟悉

二是寫自動化腳本的時候，只能用命令行啊，比如自動測試和部署腳本，無論是shell腳本還是py腳本，GUI沒法用的

最後放上快速學習GIT命令行傳送門，有基礎的話1小時足矣→ Git教程 - 廖雪峰的官方網站

GitHub Desktop是很好用的，日常用來 commit 看 log/diff 遠比 CLI 方便。但有些功能暫時都要靠 CLI，例如 submodule、tag、cherry-pick 等。維護 build 腳本時也需要 CLI。

最好 GUI/CLI 都懂，到操作的時候哪個方便用哪個。

要我就反問他平時發郵件是用telnet port 25的嗎？

另外面試官是可以被投訴的你知道嗎，作為面試官嘲諷應聘者是非常不專業的行為，因為應聘者代表的只是自己，而面試官代表的整個公司。

如果是最最常見的操作，例如 status、diff 和 commit，GUI 肯定可以做得很方便。如果是常見操作，例如 checkout、rebase，GUI 也肯定要支持。但更複雜的操作就不一定有了，就算有也不知道放在哪了。

例如你不小心 amend 了錯誤的 commit，想要回到之前的 commit 並把改動 reset 出來，你該怎麼辦呢？你可以去搜索，然後 StackOverflow 會給你一個 CLI 的答案。沒人會給你 GUI 答案的，因為 GUI 各不一樣，大家無法溝通。這最終就是個溝通的問題，如果世界上 80% 的人用同一個 GUI，各種問題都好解決。就你用 GUI，你遇到問題了就自己解決吧。

此次還有 scripting 的問題。CLI 可以用在更複雜的 script 裡面提高自動化，GUI 很難。

which gs gs () { git show $(git log --oneline | peco | cut -d" " -f1) }

面試官這麼做是不對的，但是你這個問題表現得很危險。(如果是面試官來知乎問問題說今天面了一個人只會GUI那就是另一個答案了)

沒有什麼高貴的，要完成任務當然是選擇最合適的工具而不是逼格最高的工具。我平時大部分情況下用 SourceTree 的，但是有的時候還得上 CLI。

我要是面試官，就這麼問你

如果我一次提交信息寫錯了，怎麼修正？
如何撤銷一次 commit，使這次 commit 重新回到暫存區？
如何給比較兩次不同的提交，生成一個補丁文件，給自己的同事？
如何同事向兩個遠端倉庫提交代碼，一個在Github，另一個在公司的Gitlab伺服器
如果我現在修改了一點東西，不想提交，但是在另一個分支上有一個緊急的 bug 需要你來修復，你會怎麼做？
如何用最新的 master 分支覆蓋自己的本地分支
怎麼 revert 一個 revert ，讓他看起來像沒有 revert 一樣

如果這些你都有答案的話，那隻用 GUI 沒一點問題

你就說你用 tig 嘛，妥妥的兩頭堵啊……

那些嘲諷題主只會git的簡單功能的，你們來給我解釋一下你們在你們工作流程里都是怎麼使用git update-ref， git commit-tree或者git update-index的。

一般 Git 的圖形化操作工具提供的功能都是命令行功能的子集，如果它能覆蓋你所有的需求，說明你在工作中可能的確沒有遇到過一些版本管理方面比較複雜的場景。與其在圖形界面和命令行之間切換，還不如直接用命令行來得高效。

鄙視鏈是客觀存在的，人家好不容易學會複雜難掌握的工具，鄙視下就鄙視下唄。關鍵還是看你自己用什麼工具效率最高，自己覺得最順手。

也不是說多麼高貴。

面試官的問題在於，心有點窄。

Git GUI能完成不少日常操作，這並不是說Git GUI和Git CLI在功能上是等價的。通常Git GUI的功能只是Git CLI的真子集，而且想玩轉一些關於Git的黑科技還是要靠命令行。

但Git GUI真正的問題不在於low，而在於難用。這不僅體現在Git GUI的多樣化方面，還體現在Git GUI本身。Git的圖形客戶端有Tortoist、gitg、SourceTree、Github Desktop等。這種多樣性本身就是問題，它們都不能達到「在任何場景下方便操作」的程度。儘管其中SourceTree算是尚好，至少看代碼方便，但不論是哪個客戶端，想執行一些稍微高級點的操作都要點開層層菜單才能找到相應的按鈕，更不用說這些客戶端視圖布局不一致，你根本不知道功能藏在哪。

而實際上，Git GUI的問題不在於放按鈕式的用戶交互不友好，而在於i18n問題。也不知道是不是我語死早，鬼知道「變基」是rebase的意思！所以對於大部分中國的程序員，只用Git GUI是根本用不明白的。

上述問題，在命令行中根本不是問題。嫌命令行複雜的話，寫alias啊。不會用的話，就承認不會用，被說low就覺得委屈了？不會就是不會，你去學就是了。反正我從來沒見過純Git GUI用戶比命令行用戶對Git有更深入的了解。

Git從一開始就是命令行工具，後來才衍生出多個圖形界面工具，但如上所述，Git命令行是經得起歷史考驗的，而Git圖形界面工具還在被考驗、還在打磨。

但，題主我知道你覺得自己委屈，感覺自己被鄙視了一臉。你當時應該反殺，你應該告訴面試官，用Git GUI照樣可以完美執行開發工作流，跟面試官講講Git里的緩衝區、指針、鎖、本地伺服器同步的原理究竟是怎樣的，也告訴面試官Git中的場景弊端、性能瓶頸是怎樣的，最後再分析一下之前某個版本（我記得是2.6.4）中遠程任意執行漏洞的具體細節。

別委屈了，你現在就跟他講這些，你立刻就能翻盤。題主加油！

面試都是相互的，這種SB公司顯然就不能去

我們IBM內部有一個代碼管理工具，其工作機制和git很像，但是叫SCM，是Rational Team Concert的一部分，然而我交了無數代碼，我都記不住命令，只會GUI交。

我覺得這東西，核心在於代碼管理，理解一下這套代碼管理的機制可以，問git是否熟悉，我還以為他會問git的工作機制以及與SVN的不同，但是他好逗比呀，竟然問是不是使用命令行，哈哈哈...我覺得交代碼，你管我命令行還是GUI，你看的是我交的代碼還是我交代碼的方式，本末倒置啊。

git可以在任何地方操作。

怎麼舒服怎麼來，怎麼方便怎麼來，這是我一貫的原則。

我一般用命令行操作比較多，當我處於CLI的環境下，我直接用CLI難道不是最方便的？

開發一個項目時，我至少會開一個terminal，把工作目錄定位到項目目錄。我剛剛對文件進行了一次mv操作，直接用gst就可以查看狀態，難道我還要另外開一個工具，然後把手移動到滑鼠上，在工具里打開項目目錄查看狀態？（我設了alias gst=git status）

如果我用vim來編輯一個項目，假如我的vim沒有git插件，我只需要按6個鍵就可以查看status，如果有git插件，自帶文件狀態的顯示，豈不是更加方便？vim也是運行在terminal之上，這種情況算不算是用命令行的git啊？

如果我用IDE（習慣用jetbrains的IDE），那我直接用jetbrains集成的git也很方便啊。

沒用過單獨的git gui我不了解，但是jetbrains集成的git我可以說一下，一開始我是不會使用的，因為它把git重新包裝過一次，沒有cli直觀，cli可以自動補全，還可以很方便地看幫助。很多操作在IDE集成的git上都沒找到，或者不容易找到，這時候我會用cli。

我曾經試圖找個gui的git客戶端，樓上說的sourcetree並沒看到有Linux的版本，網上了解了幾款Linux下的gui客戶端，但大家沒有特別統一的意見，選擇太多遂放棄。

CLI我受不了的是merge功能，文件多一點，用cli來merge都不方便，這裡我會用IDE來merge。

問題要對照來看才有意思：

git裡面怎麼查看某個提交時指定文件的具體內容? - Git - 知乎

============================以下是原答案==============================

我們團隊使用過hg和git，根據以往的經歷，發生代碼提交、合併、覆蓋錯誤的，使用命令行的佔90%以上！（注意：1）我不是說GUI永遠不出問題， 2）我不是說使用命令行出錯概率是90%，而是說出錯的人中90%是使用命令行的）

原因在於真正花時間去熟悉命令行、參數、運行原理的人並不多，大部分人都是懶的，時間也是不夠的，使用命令行的時候，都是「試探性使用」，執行一個命令，沒有錯，萬事大吉；有錯，再去看看幫助，咦，這個參數好像有用哦？試試。。。。。。成功了，o yeah。。。。。失敗了，再看看幫助，咦，另外一條命令好像是解決問題的哦，再試試。。。。。。

這種方式，運氣好，問題解決；運氣不好，搞出大事件！！

所以我都是推薦團隊優先使用GUI，個別牛人不喜歡GUI沒關係，你別用CLI搞出問題即可；至於說寫腳本之類的，那是少數人，大部分人不可能去寫git的腳本的。（注意：我沒有說牛人用git不行，我也沒有說沒有人會去寫git腳本）

對了，GUI用了烏龜系列，現在用smartgit，功能都很強大，界面設計都很好，個人更喜歡smartgit

======================2016.11.24補充====================

特別加了幾個括弧並且加上「注意」的內容，不然還是有人理解不對

=====================2016.11.24 二次補充=================

很多人將我的答案理解成是「GUI大法好，CLI是垃圾」，我向各位道歉，是我沒說清楚，其實我想說「CLI大法好，但GUI已經對大部分人夠用了」！

各位捍衛CLI的衛士，你們個人的經驗和經歷都是很厲害的，但以為全中國程序員個個都像你們那麼牛逼，個個都像你們那麼有鑽研精神，個個都像你們那麼有時間去研究，我覺得這不是現實，當然，也許是我一直都是垃圾團隊當個垃圾主管也是可能的，我沒有做過專業統計也沒有做過專業調查。

這個面試官也很不專業。連GUI都不會用，指望他會用命令行？（逃

實踐表明，sourcetree和命令行一起用才是墜吼滴！

看你描述的，並不覺得這面試官Git命令行就玩得很6。不過題主確實可以去學一下命令行，這樣下次你就能反殺了，加油！

兩個都用啊，各有各的優缺點，沒必要一棒子打死。

基本操作，提交一眼就能看到基本的diff，分支明確，看一眼就能明白，換成命令行，得好幾條指令，一點點看。

對新手友好，過渡期會比較舒適。

命令行對一些複雜操作和自定義腳本操作要好的多，或者說這些拿gui根本沒法搞。用順了，也挺快的。

分情況討論吧，各有千秋的東西，不討論場景就說哪個好，不是那麼合適。

首先搞清概念，github是一個代碼託管網站，也就是一個server，按照wiki的說法就是：

GitHub is a web-based Gitrepositoryhosting service. It offers all of the distributed version control andsource code management (SCM) functionality of Git as well as adding its own features.

Github存放你的代碼，上面部署了git server。

而git是一個版本管理軟體，也就是：

Git is a version control system that is used for software development

and other version control tasks.

使用git可以向github上提交代碼。以我看這面試者連基本概念都搞不懂，還不如我這個前IT從業者呢！摔！

ps：補充StackOverflow上對這兩個的解釋：

[1]Git (software)

[2]GitHub

[3]Difference between Git and GitHub

tortoisegit差不多已經是我唯一使用windows的理由了。試遍了mac上的git gui客戶端，沒有一個合心意的。

至於命令行，啊，有好幾年沒用過了。至於說熟不熟，提過幾個沒被接受的patch，不知道算熟還是不熟，照git team那幫鳥人的角度來看，應該算是不熟的，總挑我的毛病，真是討厭呢。

=============

多謝評論裡面給我推薦的朋友們，但這些我基本都試過，都不合心意。簡單的說，我為什麼喜歡tortoisegit勝過其他gui工具：

1. 不需要導入項目。我日常工作大概要跟超過30個repository打交道，對那些需要導入項目的gui來說，且不說每次都要導入項目管理是個麻煩事，導入之後，在那些工具的界面裡面超過30個項目，視覺是非常糟糕的，而且，也幾乎沒法管理。而tortoise沒有這個問題，我的項目分布在不同的目錄中，自然的隔離開，我每次只跟一個repository打交道就可以了。同時，換個角度，我可以同時打開多個相關項目的log做比較，這個更加方便了。

2. 功能完整。這個答案下的很多GUIer都會提到說，啊，某些高級功能GUI的確不方便，還是要用命令行的。但是，tortoise包含了超過99%的功能，在我超過6年的git使用經歷中，我還沒有發現不得不用命令行來完成的日常工作。嚴格的說，是有過的，早期tortoise合併patch文件有點小問題，我有時不得不在命令行下合併patch文件，在開發組非常友好的fix了我提交的報告之後，嗯，現在這個需求也已經不需要命令行了。