git bash命令設計不合理的地方

本月17日左右開始學習git，到現在10天左右，也只學了一點皮毛。

我對git的了解為三個階段：

1. 2012年初，當時在網上看到git，就安裝來玩了一下。由於不理解其原理，命令行和圖形界面都不會操作。當時網上漢文資料比較少，我就放棄了。
2. 2015年中，我賦閒自學期間，又在虛擬機中安裝了git，想嘗試一下。結果由於對SSH不熟，代碼 clone 失敗，又放棄了。兩年我前已經系統地學習過SVN，對版本控制系統有一定的了解了，此時學習git應該不是難事，但是因為時間緊迫，急於求成，最終放棄。
3. 進入現在這家公司後，由於工作需要，不得不再次學習，並且還要學扎實。我發現用https協議也能 clone ，然後就開始嘗試在本地用bash命令來進行 add  commit  push 等操作。為了熟悉常用的命令，我在電腦上進行反復練習，直到達到可以不用想就能打出來的程度為止。

我目前掌握的程度還很淺，而且也不打算學太深，因為可能用不到。但是仍然想寫一篇簡單的文章，來介紹git，并交流一下自己的心得。

不論是SVN還是git，他們都有自己的設計模型。一個系統是否易學，很大程度上取決於其模型設計是否科學合理並且結構明晰。我以前系統地看過SVN，覺得這個系統的設計，結構就很明晰。而git，學得不夠，還沒法評價。很多人說git學習成本高，我想，可能就是因為他的模型複雜，用幾幅簡單的圖，難以讓學習者理解其原理和對應的API。

git從一開始，就是用bash命令來操作的，後來才有了UI client。這導致一個後果，就是幾乎所有的教程，都是通過bash命令來講解git，而不是圖形界面。如果一個人經過長期的學習，已經掌握了bash命令，那麼一般是不願意也沒必要重新去學習圖形工具的。而如果從一開始就想通過圖形工具來學，又會發現，自己的認知程度，還無法把圖形界面上的內容跟教程中的內容準確地聯繫起來，最終不得不放棄。

git命令的設計，總體來說，可能是很精妙的。我目前對他總體的認識還很少，只能談談某些細節。 git diff 的設計，似乎就有點不合理。要比較work tree stage commit三者之間的差異，用三個命令來操作。他們都是用 git diff 命令，然後攜帶不同的參數。這裡有一個問題，這三者之間的比較操作，在邏輯上是有很強的相關性的，那麼 git diff 命令的參數就理所當然地也應該具有相似性。而實際的情況是，一個不帶參數，一個帶 --stage 形式的參數名和值，一個帶沒有參數名的參數。

可能，其自有其內在的合理性，只是我並不清楚而已。但至少在外在表現上，其API設計是不太合理的。

另外一個問題，branch和file級別的數據還原，用 git checkout ，而commit級別的數據還原，則用 git reset ，這個表現也很怪異。我想，其設計的目標應該是這樣： git checkout 是用於修改HEAD指針指向的，可以針對branch commit file三個粒度來操作； git reset 則是用於內容的還原，可以控制commit stage work tree三個級別。這樣的設計似乎是清晰合理的，但是在實際應用中， git checkout commit 幾乎是沒用的（操作後會be in a detached head state），所以commit級別的數據回退，是用 git reset 來完成的。這就使得git的API，外在的表現很混亂。

最後，列一些相關的資源：

教程：

http://alx.github.io/gitbook/
http://www.git-scm.com/book/
http://git.oschina.net/progit/index.html
http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

官網：

https://git-for-windows.github.io/
http://www.git-scm.com/

工具：

https://www.sourcetreeapp.com/
https://tortoisegit.org/