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 "[email protected]" -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
clipboard.png

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

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

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

clipboard.png

將項目克隆到本地

在電腦本地的一個目錄中

git clone ssh://[email protected]/courseware/share-plane/git.git

然後第一次連接會出現讓確認主機:

大概意思是,無法確認host主機的真實性,只知道它的公鑰指紋,問你還想繼續連接嗎?

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

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

沒有找到我們公司公佈的git.xes.com這個域名下的SSH指紋信息,但是類似的比如GitHub我們可以找到公佈的指紋信息如下圖:

clipboard.png

我們接受這個指紋(一般情況內網沒有壞人)繼續向下走.

系統會出現一句提示,表示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:[email protected]/courseware/share-plane/git.git

這樣做的唯一的缺點就是,別人通過你本地電腦可能不小心看到你的密碼哦。

git config配置緩存認證信息

git config --global credential.helper store

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章