Git是一款可以替代SVN對程式碼版本進行管理的工具，近幾年，這款由大神Linus開發，託管著linux核心程式碼的小軟體大有在國內徹底取代SVN的架勢。

Git雖說很強大，不論是多分支開發，分散式程式碼庫都像重慶小火鍋一樣讓人吃上一口就再也無法停下來，但是Git也有一個很“嚴重”的問題，那就是沒有許可權控制功能。Git的建立是作為開源社群的程式碼版本管理工具而存在的，但當我們把Git引入到團隊內部的開發流程中後就會發現沒有許可權控制的GIT無法保護核心程式碼的安全，有時候一段錯誤的程式碼神不知鬼不覺的出現在底層類庫中造成災難性的後果。

幸好還有SSH。

由於Git的主流連線方式是SSH連線，因此當我們試圖控制一個Git中心庫許可權的時候，可以通過控制SSH登入使用者的許可權來間接的達到目的。

那如何控制SSH的使用者許可權呢？既然我們SSH到中心庫的時候用的可能都是GIT使用者（Linux的使用者），又如何區分到底真是使用者是誰呢？這裡就不得不說SSH的公私鑰模式，當我們將某一個使用者生成的公鑰新增到GIT使用者的  ~/.ssh/authorized_keys 檔案後，以該使用者身份SSH連線到GIT使用者時可以免去輸入密碼的步驟。而Git許可權控制的關鍵環節就在這個authorized_keys檔案中。

一般典型的authorized_keys檔案每一行都是一個公鑰串，簡單直接，但其實這個檔案可以支援更豐富的SSH連線模式，請看下方的截圖

很顯然，這裡面除了公鑰之外還包括幾個其他的配置：

command：以該公鑰對應的私鑰登陸後執行的廚師命令

no-xxxxx：表示不支援該模式的連線

最後才是對應的公鑰。

如此配置的話，如果使用者試圖使用SSH預設連線方式會得到如下的返回結果

這樣可以限制使用者不可以毫無顧忌的連線到Git使用者進而繞過SSH的許可權控制系統。而每次Git的push/pull/clone等操作其實都是一次SSH連線從而啟用command命令而執行指令碼。

那麼剩下的就好解釋了，指令碼接受引數，然後去做使用者許可權的判斷，如果使用者具有許可權那麼直接執行SSH連線附帶的命令請求，如果沒有許可權直接exit 1就好啦。