Git 入門指南-協議

Git 入門指南-協議

前言

講到Git協議，一般狀況下咱們須要與其餘人的git倉庫進行推送或拉取資料，與別人通訊是須要使用到協議。

最佳協做實踐

創建一個你與合做者們都有權利訪問，且可從那裏推送和拉取資料的共用倉庫。

注意：使用git，技術上是能夠實現，從我的倉庫進行推送（push）和拉取（pull）來修改內容，但不方便。

Git中的四種主要協議

• 本地協議（Local）
• HTTP 協議
• SSH（Secure Shell）協議
• Git 協議。

  在此，咱們將會討論那些協議及哪些情形應該使用（或避免使用）他們。

本地協議

版本庫就是硬盤內的另外一個目錄。

你能夠像下面這樣：

git clone /git/project.git # clone一個本地項目到新的目錄。
git remote add local_proj /git/project.git # 添加project爲當前庫的遠程庫(本地引用local_proj)

優勢

簡單，直接使用現有的文件權限，速度快(不進行遠程操做的話，就是磁盤的讀寫速度)，

缺點

創建版本庫協做須要共享文件系統，不方便從多個物理位置訪問（家，公司，出差點等）。

值得一提的是，若是你使用的是相似於共享掛載的文件系統進行遠程協做時，這個方法不必定是最快的。 訪問本地版本庫的速度與你訪問數據的速度是同樣的。 在同一個服務器上，若是容許 Git 訪問本地硬盤，通常的經過 NFS 訪問版本庫要比經過 SSH 訪問慢。

最終，這個協議並不保護倉庫避免意外的損壞。 每個用戶都有「遠程」目錄的完整 shell 權限，沒有方法能夠阻止他們修改或刪除 Git 內部文件和損壞倉庫。

HTTP協議

Git 經過 HTTP 通訊有兩種模式。 在 Git 1.6.6 版本以前只有一個方式可用，十分簡單而且一般是隻讀模式的。 Git 1.6.6 版本引入了一種新的、更智能的協議，讓 Git 能夠像經過 SSH 那樣智能的協商和傳輸數據。新版本的 HTTP 協議通常被稱爲「智能」 HTTP 協議，舊版本的通常被稱爲「啞」 HTTP 協議。

智能（Smart） HTTP 協議

「智能」 HTTP 協議運行在標準的 HTTP/S 端口上而且可使用各類 HTTP 驗證機制，這意味着使用起來會比 SSH 協議簡單的多，好比可使用 HTTP 協議的用戶名／密碼的基礎受權，免去設置 SSH 公鑰。

智能 HTTP 協議即支持像 git:// 協議同樣設置匿名服務，也能夠像 SSH 協議同樣提供傳輸時的受權和加密。 並且只用一個 URL 就能夠都作到，省去了爲不一樣的需求設置不一樣的 URL。 若是你要推送到一個須要受權的服務器上（通常來說都須要），服務器會提示你輸入用戶名和密碼。 從服務器獲取數據時也同樣。

事實上，相似 GitHub 的服務，你在網頁上看到的 URL （好比， https://github.com/schacon/simple.git)，和你在克隆、推送（若是你有權限）時使用的是同樣的。

啞（Dumb） HTTP 協議

SSH 協議

架設 Git 服務器時經常使用 SSH 協議做爲傳輸協議。 由於大多數環境下已經支持經過 SSH 訪問 —— 即便沒有也比較容易架設。 SSH 協議也是一個驗證受權的網絡協議；而且，由於其廣泛性，架設和使用都很容易。

經過 SSH 協議克隆版本庫，你能夠指定一個 ssh:// 的 URL：

$ git clone ssh://user@server/project.git

你也能夠不指定用戶，Git 會使用當前登陸的用戶名。

優點

SSH 架設相對簡單，使用普遍，多數操做系統都包含了它及相關的管理工具，安全，會壓縮數據。

缺點

不能匿名只讀訪問。

因此，即使只要讀取數據，使用者也要有經過 SSH 訪問你的主機的權限，這使得 SSH 協議不利於開源的項目。 若是你只在公司網絡使用，SSH 協議多是你惟一要用到的協議。 若是你要同時提供匿名只讀訪問和 SSH 協議，那麼你除了爲本身推送架設 SSH 服務之外，還得架設一個可讓其餘人訪問的服務。

Git 協議

Git 裏的一個特殊的守護進程；它監聽端口（9418），相似於 SSH 服務，可是訪問無需任何受權。 要讓版本庫支持 Git 協議，須要先建立一個 git-daemon-export-ok 文件 —— 它是 Git 協議守護進程爲這個版本庫提供服務的必要條件 —— 可是除此以外沒有任何安全措施。 要麼誰均可以克隆這個版本庫，要麼誰也不能。 這意味着，一般不能經過 Git 協議推送。 因爲沒有受權機制，一旦你開放推送操做，意味着網絡上知道這個項目 URL 的人均可以向項目推送數據。 不用說，極少會有人這麼作。

優勢

目前，Git 協議是 Git 使用的網絡傳輸協議裏最快的。 若是你的項目有很大的訪問量，或者你的項目很龐大而且不須要爲寫進行用戶受權，架設 Git 守護進程來提供服務是不錯的選擇。 它使用與 SSH 相同的數據傳輸機制，可是省去了加密和受權的開銷。

缺點

Git 協議缺點是缺少受權機制。 把 Git 協議做爲訪問項目版本庫的惟一手段是不可取的。 通常的作法裏，會同時提供 SSH 或者 HTTPS 協議的訪問服務，只讓少數幾個開發者有推送（寫）權限，其餘人經過 git:// 訪問只有讀權限。 Git 協議也許也是最難架設的。 它要求有本身的守護進程，這就要配置 xinetd 或者其餘的程序，這些工做並不簡單。 它還要求防火牆開放 9418 端口，可是企業防火牆通常不會開放這個非標準端口。 而大型的企業防火牆一般會封鎖這個端口。

在代碼託管服務使用SSH協議協做

使用SSH協議，你能夠鏈接和驗證遠程服務器和服務。使用SSH祕鑰，你能夠在每次鏈接GitHub或者Gitlab時，不須要用戶名和密碼。

檢查是否已經存在SSH祕鑰？

在生成新的SSH祕鑰對以前咱們應該檢查一下咱們的系統中是否已經有生成過祕鑰，由於沒有特別用途咱們沒有必要使用多對祕鑰，若是沒有找到祕鑰對，那就須要新生成祕鑰。

cd ~/.ssh/ 目錄咱們能夠查看到已經生成過的祕鑰對。

Note: 公鑰可能被命名爲以.pub爲擴展的文件名，以下:

id_dsa.pub
id_ecdsa.pub
id_ed25519.pub

新生成祕鑰

使用你的郵箱生成一個新的祕鑰。

ssh-keygen -t rsa -C "your.email@example.com" -b 4096

這裏會有幾個提問：

1. Enter file in which to save the key (/Users/rs/.ssh/id_rsa)？

鍵入你想把祕鑰保存在哪（/Users/rs/.ssh/id_rsa）？

解釋：括號中是一個默認路徑/Users/rs/.ssh/和文件名id_rsa, 鍵入enter就會使用默認，這裏須要注意，若是使用建議路徑，SSH客戶端將自動找到配置文件，不然可能須要本身調整配置。

另外，若是你建議路徑已經有祕鑰對，你將須要鍵入一個新的祕鑰路徑，並在./ssh/config文件中配置哪個SSH祕鑰對用在那個host上, 好比下面配置。

# GitLab.com server

Host gitlab.com
RSAAuthentication yes
IdentityFile ~/.ssh/config/private-key-filename-01

# Private GitLab server

Host gitlab.company.com
RSAAuthentication yes
IdentityFile ~/.ssh/config/private-key-filename

1. Enter passphrase (empty for no passphrase)?

   鍵入訪問私鑰須要的密碼，留空表明不須要密碼，通常狀況咱們祕鑰都在本身我的電腦上，無需加密，省去加密過程，留空，鍵入enter。

這樣咱們就在~/.ssh目錄下生成了id_rsa私鑰和id_rsa.pub公鑰這樣一對祕鑰，咱們複製id_rsa.pub的文件內容到剪貼板。

打開公司的gitlab網站，輸入本身的用戶名和密碼，進入本身的帳號頁面，找到帳號的配置頁面，找到SSH Keys標籤頁，將咱們複製的內容粘貼到Key下面的輸入框中, 以下圖，注意請用本身的郵箱生成祕鑰，我這裏使用的是示例郵箱。

image-20181015173217998.png

這樣咱們就配置完成了SSHkey了

該如何使用SSH來推送更新呢

當咱們配置好SSH後，咱們找到咱們的項目，好比這裏我以git項目爲例，選擇SSH，而後咱們就能夠獲取到一個SSH協議的git倉庫地址,點擊地址後面的複製按鈕，將倉庫地址複製到剪貼板中。

將項目克隆到本地

在電腦本地的一個目錄中

git clone ssh://git@git.xes.com/courseware/share-plane/git.git

而後第一次鏈接會出現讓確認主機：

大概意思是，沒法確認host主機的真實性，只知道它的公鑰指紋，問你還想繼續鏈接嗎？

所謂"公鑰指紋"，是指公鑰長度較長（這裏採用RSA算法，長達1024位），很難比對，因此對其進行SHA256計算，將它變成一個256位的指紋。上例中是SHA256:wixrNcpES0GdcUsWCvjbYYuanhmaMvgvmDSHZA9u+dA，再進行比較，就容易多了。

很天然的一個問題就是，用戶怎麼知道遠程主機的公鑰指紋應該是多少？回答是沒有好辦法，遠程主機必須在本身的網站上貼出公鑰指紋，以便用戶自行覈對。

沒有找到咱們公司公佈的git.xes.com這個域名下的SSH指紋信息，可是相似的好比GitHub咱們能夠找到公佈的指紋信息以下圖：

咱們接受這個指紋（通常狀況內網沒有壞人）繼續向下走.

系統會出現一句提示，表示host主機已經獲得承認。

Warning: Permanently added 'host,12.18.429.21' (RSA) to the list of known hosts.

而後，會要求輸入密碼，若是你在生成祕鑰對的時候對私鑰進行加密了，就須要輸入密碼。

Password: (enter password)

若是密碼正確，就能夠登陸了。

當遠程主機的公鑰被接受之後，它就會被保存在文件$HOME/.ssh/known_hosts之中。下次再鏈接這臺主機，系統就會認出它的公鑰已經保存在本地了，從而跳過警告部分，直接提示輸入密碼。

這樣配置以後，咱們即可以在本地進行ssh鏈接倉庫， 這也是大多數開發者會使用的最通用最廣泛的方式，也是github和gitlab推薦的方式。

其餘的鏈接方案

url帶受權信息

固然更簡單的方式，使用智能HTTP的方式進行登陸和推送內容：

好比: https://username:password@git.xes.com/courseware/share-plane/git.git

這樣作的惟一的缺點就是，別人經過你本地電腦可能不當心看到你的密碼哦。

git config配置緩存認證信息

git config --global credential.helper store