關於Git的禮節

（這裏的內容原本是《怎樣尊重一個程序員》的一小節，但因爲Git的使用引發了很廣泛的不尊重程序員的現象，如今特別將這一節提出來單獨成文。）

Git是如今最流行的代碼版本控制工具。用外行話說，Git就是一個代碼的「倉庫」或者「保管」，這樣不少人修改了代碼以後，能夠知道是誰改了哪一塊。其實無論什麼工具，不論是編輯器，程序語言，仍是版本控制工具，比起程序員的核心思想來，都是次要的東西，都是起輔助做用的。但是Git這工具彷佛特別惹人惱火。

Git並不像不少人吹噓的那麼好用，其中有明顯的蹩腳設計。跟Unix的傳統一脈相承，Git沒有一個良好的包裝，設計者把本身的內部實現細節無情地泄露給了用戶，讓用戶須要琢磨者設計者內部到底怎麼實現的，不然不少時候不知道該怎麼辦。用戶被迫須要記住挺多稀奇古怪的命令，並且命令行的設計也不怎麼合理，有時候你須要加-f之類的參數，各個參數的位置可能不一致，並且加了還不必定能起到你指望的效果。各類奇怪的現象，好比"head detached"，都強迫用戶去了解它內部是怎麼設計的。隨着Git版本的更新，新的功能和命令不斷地增長，後來你終於看到命令行裏出現了foreach，才發現它的命令行就快變成一個（劣質的）程序語言。若是你瞭解ydiff的設計思想，就會發現Git之類基於文本的版本控制工具，其實屬於古代的東西。然而不少人把Git奉爲神聖，就由於它是Linus Torvalds設計的。

Git最讓人惱火的地方並非它用起來麻煩，而是它的「資深用戶」們居高臨下的態度給你形成的心理陰影。好些人由於本身「精通Git」就覺得高人一等，擺出一副專家的態度。隨着用戶的增長，Git最初的設計愈來愈被發現不夠用，因此一些約定俗成的規則彷佛愈來愈多，能夠寫成一本書！跟Unix的傳統一脈相承，Git給你不少能夠把本身套牢的「機制」，到時候出了問題就怪你本身不知道。因此你就常常聽有人煞有介事的說：「並非Git容許你這麼作，你就能夠這麼作的！Unix的哲學是不阻止傻人作傻事……」 若是你提交代碼時不知道Git用戶一些約定俗成的規則，就會有人嚷嚷：「rebase了再提交！」 「不要push到master！」 「不要merge！」 「squash commits！」 若是你不會用git submodule之類的東西，有人可能還會鄙視你，說：「你應該知道這些！」

打個比方，這樣的嚷嚷給人的感受是，你得了奧運會金牌以後，把練習用的器材還回到器材保管科，結果管理員對你大吼：「這個放這邊！那個放那邊！懂不懂規矩啊你？」 看出來問題了嗎？程序員提交了有高價值的代碼（奧運金牌），結果被一些自認爲Git用的很熟的人（器材保管員）厲聲呵斥。

一個尊重程序員的公司文化，就應該把程序員做爲運動健將，把程序員的代碼放在尊貴的地位。其它的工具，都應該像器材保管科同樣。咱們尊重這些器材保管員，然而若是運動員們不懂你制定的器材擺放規矩，也應該表示出尊重和理解，說話應該和睦有禮貌，不該該騎到他們頭上。因此，對於Git的一些命令和用法，我建議你們向新手介紹時，這樣開場：「你原本不應知道這些的，但是如今咱們沒有更好的工具，因此得這樣弄一下……」