git bash命令設計不合理的地方
本月17日左右開始學習git,到現在10天左右,也只學了一點皮毛。
我對git的了解為三個階段:
- 2012年初,當時在網上看到git,就安裝來玩了一下。由於不理解其原理,命令行和圖形界面都不會操作。當時網上漢文資料比較少,我就放棄了。
- 2015年中,我賦閒自學期間,又在虛擬機中安裝了git,想嘗試一下。結果由於對SSH不熟,代碼 clone 失敗,又放棄了。兩年我前已經系統地學習過SVN,對版本控制系統有一定的了解了,此時學習git應該不是難事,但是因為時間緊迫,急於求成,最終放棄。
- 進入現在這家公司後,由於工作需要,不得不再次學習,並且還要學扎實。我發現用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/
工具: