Git 指令實踐：遠端儲存函式庫同步與高用性架構

– 12 分鐘閱讀

在團隊開發中，透過 Git 同步程式碼至遠端儲存函式庫如 GitLab 是不可或缺的環節。每個開發者在本地端擁有儲存函式庫副本，並透過與 GitLab 上的黃金儲存函式庫互動來同步變更。同步的過程包含推播本地提交至遠端，以及從遠端提取其他開發者的提交。組態遠端儲存函式庫是同步的前提，可透過 git remote --verbose 檢視已設定的遠端儲存函式庫資訊。建立本地儲存函式庫副本的方式包含 git init 和 git clone，其中 git clone 會自動設定遠端儲存函式庫。使用 SSH 協定連線遠端儲存函式庫更為安全，需事先設定 SSH 金鑰並將公鑰新增到 GitLab。推播分支到遠端儲存函式庫使用 git push 指令，第一次推播需要設定上游分支名稱。git fetch 指令用於取得遠端儲存函式庫的更新資訊，而 git pull 則會將遠端分支的變更下載並合併到本地分支。

基本 Git 指令實踐

在 GitLab 上的「黃金儲存函式庫」是儲存函式庫的主要副本。如果你的開發團隊有 20 名開發者，那麼至少會有 21 個這個專案儲存函式庫的副本：每個開發者電腦上各一個，還有一個在 GitLab 例項上。如果 GitLab 例項所在的電腦因某些原因無法使用，你可以暫時將某個開發者電腦上的儲存函式庫指定為團隊的黃金儲存函式庫。不過，一旦 GitLab 例項還原正常，應該立即還原使用其副本作為黃金儲存函式庫。

當我們談論同步不同副本之間的修改時，這些同步動作總是透過 GitLab 例項進行。換句話說，如果我在本地電腦上對儲存函式庫進行了提交並希望讓同事們看到這些提交，我不是直接把這些提交傳送到每個同事的電腦上。相反，我會把我的提交傳送到黃金儲存函式庫，然後每個開發者都會從黃金儲存函式庫中取得我的提交。

以下圖示展示了一個工作流程，允許一名開發者將其提交分享給另一名開發者，透過將包含這些提交的分支推播到並從黃金儲存函式庫提取：

  graph LR
    A[開發者 1] -->|推播分支| B[黃金儲存函式庫]
    B -->|提取分支| C[開發者 2]

組態遠端儲存函式庫

在同步你的本地儲存函式庫與黃金儲存函式庫之前，Git 必須知道黃金儲存函式庫的存在。任何不在你本地電腦上的儲存函式庫副本都稱為「遠端」，因此同步提交的一個重要先決條件是組態遠端。

你可以使用以下指令來檢視 Git 已知的任何遠端名稱和 URL 的列表：

git remote --verbose

同步本地和遠端的儲存函式庫副本

之前，我們描述了兩種將儲存函式庫複製到電腦上的方式：git init 和 git clone。如果你在使用 git init 建立的儲存函式庫中要求 Git 提供遠端列表，它將不會有任何輸出。它還不知道任何遠端，因為你尚未告訴它任何遠端。但如果你使用 git clone 將一個儲存函式庫複製到你的機器上，那麼 Git 已經知道一個遠端：你所克隆的那個副本。

在進一步討論之前，讓我們先了解如何克隆一個儲存函式庫。如前所述，這是最常見的將一個儲存函式庫複製到電腦上的方式，因此這是一個需要熟悉的重要做法。

你可以從你的本地電腦能夠網路連線到的一台電腦上克隆一個儲存函式庫，但讓我們集中關注從 GitLab 例項上克隆一個儲存函式庫。假設這個例子中的儲存函式庫由 www.gitlab.com 上的 GitLab 例項主機提供。如果你使用的是自託管版本的 GitLab 而不是這個例子中使用的軟體即服務（SaaS）版本，克隆過程是相同的，只是你要克隆的儲存函式庫地址看起來會稍有不同。

要克隆一個由 GitLab 主機提供的一個儲存函式庫，你需要知道該儲存函式庫的地址。這個地址有幾種形式，但兩種最常見的是使用 HTTPS 或 SSH 協定。雖然兩種協定都可以運作，但通常更推薦使用 SSH 協定。它需要你組態 SSH 金鑰才能開始操作，但之後與這個遠端互動時就不需要再輸入憑證：鑰匙基礎設施會自動處理所有認證。

相反地，HTTPS 協定需要每次使用需要與該遠端通訊的 Git 指令時都輸入使用者名稱和密碼。

我們已經看到如何使用 git init 建立「帽子給貓」專案的檔案夾，現在讓我們轉換一下重點並假設已經有一個「帽子給貓」專案存在於 GitLab 的例項上，而你想要將它複製到自己的電腦上。

首先，你需要使用終端機中的 ssh-keygen 指令建立公鑰和私鑰並上傳公鑰到 GitLab 例項上。GitLab 有關於如何進行此操作的優質檔案可在 GitLab SSH 錄 中找到，所以我們建議參考那裡而不再重複說明這些指令。

內容解密：

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

以上指令用於生成新的 SSH 金鑰對（包含公鑰和私鑰）。-t rsa 指定生成 RSA 型別的金鑰；-b 4096 指定金鑰長度為 4096 位元；-C "your_email@example.com" 新增註解（通常是你的電子郵件）。

接著需要將生成好的公鑰上傳到 GitLab 中：

  1. 在終端機中輸入以下指令來顯示公鑰內容：
cat ~/.ssh/id_rsa.pub
  1. 複製顯示出來的公鑰內容。
  2. 前往 GitLab 網站並登入。
  3. 前往右上角使用者頭像旁邊圖示選單中的「設定」。
  4. 在左側選單中選擇「SSH 金鑰」。
  5. 在「密匙」欄位中貼上剛剛複製下來公鑰內容。
  6. 點選「新增密匙」。

接著，

  1. 前往 GitLab 頁面並登入。
  2. 在右上角點選使用者頭像旁邊圖示選單中的「設定」。
  3. 在左側選單中點選「SSH 金鑰」。
  4. 在「密匙」欄位中貼上剛剛複製下來公鑰內容。
  5. 點選「新增密匙」。

注意：只需執行一次此程式即可確保每次與該 GitLab 例項上的任意專案互動時都已完成認證。如果切換到不同的 GitLab 例項或不同本地電腦時則需重新執行此程式。

現在，

  1. 首先進入專案頁面並點選 Clone 按鈕。
  2. 在下拉選單中找到並複製標註為 Clone with SSH 的地址：
  graph TD
    A[GitLab 首頁] --> B[專案頁面]
    B --> C[Clone 按鈕]
    C --> D[Clone with SSH 地址]

最後，

  1. 測試您能否成功連線至您剛剛組態完畢且確認已成功加入 SSH 錄（Key）中的伺服器。
  2. ssh -T git@gitlab.com 是成功測試連線狀況最簡便且行之有效方法之一：

內容解密：

ssh -T git@gitlab.com

以上指令用於測試與 GitLab 的 SSH 連線狀況。「-T」引數用於防止啟動伺服器側互動式 shell。 成功回應應顯示如下文字：

Welcome to GitLab, @your_username!

如果您看到類別似以上文字回應則代表您與伺服器已成功連線且透過身份驗證流程。

接著在終端機中輸入以下指令以啟動克隆過程：

cd ~/code
git clone git@gitlab.com:cwcowell/hats-for-cats.git

以上指令用於進入您預計安放您要克隆之專案之目錄以及執行克隆過程。

克隆過程會自動定義一個遠端倉函式庫供您使用：它讓您本地倉函式庫知道有一個遠端倉庫存在於您所克隆得URL, 您可以使用以下命令來檢視這遠端倉函式庫列表：

$ git remote --verbose
origin git@gitlab.com:cwcowell/hats-for-cats.git (fetch)
origin git@gitlab.com:cwcowell/hats-for-cats.git (push)

內容解密：

$ git remote --verbose

以上指令用於檢視目前您與各遠端伺服器之關聯狀況及可透過 fetch 與 push 語法操作之目標範圍。 以上範例可視為標準及模範回應結果。 回應結果前方標記為 origin 的部分代表目前為預設之工作目標及方便理解之標記， 若想替換預設目標或是增加其他目標則需透過 git remote add 單字操作達成其功效， 而後方更多詳細語法則代表可透過 fetch 與 push 語法操作之目標及其位置資訊。（即：目的地）

此圖示展示了相關流程:

  graph TD
    A[clone] --> B[(由 URI 查詢相關資訊)]
    B --> C[(透過SSH協定聯絡並建立安全通道)]
    C --> D[(將相關資料傳遞至本地端)]
    D --> E[(檢查並驗證完整性)]

負載平衡器（Load Balancer）與高用性（High Availability）

負載平衡器主要負責分配網路流量以達到高用性與最佳化資源運用之效果。當我們進行多次無限制執行大量資料傳遞時其中產生之流量變化主要透過負載平衡器進行資源管理以避免單一伺服器被瓶頸影響而影響系統穩定性。

若想更具體瞭解負載平衡器相關技術內容可參考 AWS ELB 或 NGINX Load Balancing等相關檔案。

高用性架構設計（High Availability Architecture Design）

高用性架構設計主要關注於系統能夠在遇到故障或災難時能夠快速還原並持續執行之能力。設計高用性架構需要考慮多方面因素包括但不限於如下幾項：

  1. 冗餘設計：確保每一項重要元件皆有備份以防止單點失敗影響系統運作。
  2. 自動容錯移轉：系統應具備自動檢測與轉移能力以確保故障時能夠快速切換至備援系統而不影響服務運作。
  3. 資料備份與還原：定期備份重要資料並具備快速還原能力以防止資料遺失或損毀。
  4. 監控與警示：佈署全面監控系統以隨時追蹤系統狀態並設定警示機制及時通知管理員處理問題。

負載平衡策略（Load Balancing Strategy）

負載平衡策略主要涉及如何分配網路流量以達到最佳化資源運用及提高系統穩定性之效果。常見負載平衡策略包括但不限於：

  1. 輪詢分配（Round Robin）：依照順序將請求分配至不同伺服器。
  2. 加權輪詢（Weighted Round Robin）：依據各伺服器之處理能力分配請求數量以達到最佳化負載分配效果。
  3. 最少連線數（Least Connections）：將請求分配至目前連線數最少之伺服器以均衡負載。
  4. IP 雜湊（IP Hash）：根據客戶端 IP 地址雜湊值決定請求分配位置以確保同一客戶請求始終分配至同一伺服器。

高用性雙機組態

高用性雙機組態 是指將兩台或多台伺服器組態成互為備援狀態以確保當其中一台伺服器出現故障時另一台仍能持續提供服務並快速接管處理所有請求。

組態流程：

  1. 設定主從關係：主伺服器負責處理所有請求並將資料同步至從伺服器。
  2. 監控健康狀態：定期檢查主從兩台伺服器之健康狀態以確保當前處理能力能夠維持正常運作。
  3. 自動容錯移轉：當主伺服器出現故障時自動切換至從伺服器繼續提供服務。
  4. 資料同步機制：確保從伺服器能夠即時取得主伺服器最新更新資料以避免因切換造成資料不一致問題。

機房基礎設施設計（Data Center Infrastructure Design）

良好機房基礎設施設計對於確保系統穩定執行、降低風險及提升效率具有重要意義：

  1. 冷熱通道設計：合理佈局冷熱通道以降低冷氣消耗、提高散熱效率及降低能耗。
  2. 電力供應系統設計：採用 UPS 不斷電系統及雙路供電組態以確保穩定供電無幹擾。
  3. 防火防盜設計：安裝全面監控系統及防護措施以防止非法進入或破壞裝置安全。

資料中心專業技術人員要求

除了基本硬體知識外還需具備多方面專業技能包括但不限於如下幾項：

  1. 網路管理與維護能力：熟悉網路裝置組態、除錯與維護技術；具備良好的故障排除能力及網路安全知識。
  2. 虛擬化技術掌握：熟悉 VMware、Hyper-V、KVM等虛擬化技術及相關管理工具；具備虛擬機器建立、遷移、調整及安全策略設定能力。
  3. 雲平台操作經驗：熟悉 AWS、Azure、Google Cloud等雲平台基礎設施管理；具備雲基礎設施規劃、佈署及最佳化經驗；瞭解容量預測、成本控制及安全監控技術等多方面知識。

同步本地及遠端倉函式庫的基本 Git 操作

在本地及遠端之間同步 Git 儲存函式庫的過程中，您可能會遇到多個遠端倉函式庫。這些遠端可以用來接收他人的提交或傳送自己的提交。您不需要擔心這些區別，因為在大多數情況下，您可以將它們視為一個單一的遠端。在 Git 的輸出中，您可能會看到「origin」這個詞。這是因為儲存函式庫的黃金副本通常被稱為「origin」，這是由 Git 的設計者決定的。

如果您使用 git init 而不是 git clone 建立了儲存函式庫，則需要在 GitLab 例項上建立一個 Git 專案和儲存函式庫，作為遠端儲存函式庫。然後，您可以使用 git remote add 命令讓本地儲存函式庫知道這個遠端儲存函式庫的存在。由於這種工作流程比使用 git clone 更不常見，我們將讓您自行查詢此命令的語法，如果需要時。

推播（Push）

在介紹推播（push）之前，我們一直使用「傳送」來描述將本地提交複製到黃金儲存函式庫的過程。但在 Git 中，官方術語是「推播」。用於推播提交的命令是 git push。

假設您在本地儲存函式庫中建立了一個名為 login-feature 的分支，並且在該分支上增加了一些提交。現在，您希望將此分支推播到 GitLab 例項上的黃金儲存函式庫，以便您的隊友可以檢視該分支及其提交。要實作這一點，請確保您處於要推播的分支上，然後推播它。

首先，我們來瞭解一下第一次將分支推播到遠端儲存函式庫時的特殊情況：您必須告訴遠端儲存函式庫如何命名它對該分支的副本。幾乎總是希望遠端副本與本地副本具有相同的名稱。遠端副本在黃金儲存函式庫中的分支通常非正式地稱為「上游」分支。要告訴遠端儲存函式庫將上游分支命名為 login-feature，請切換到要推播的分支，然後向 git push 命令傳遞一些額外選項：

$ git switch login-feature
$ git push --set-upstream origin login-feature

注意選項中的「origin」一詞。這告訴 Git 您要將提交推播到哪個遠端儲存函式庫，即使目前只有一個遠端定義。此外，重要的是要理解：您只需設定一次上游分支名稱。從那時起，您只需執行 git push 而不附加任何其他選項即可將當前分支的提交推播到遠端黃金副本。

提取（Fetch）

至此，您已經瞭解如何將更改推播到黃金儲存函式庫以供同事檢視。但如何將他們的更改提取到本地儲存函式庫呢？首先需要了解的是 git fetch 命令。此命令會與黃金儲存函式庫通訊，檢查是否有任何人已經將新的分支或對現有分支進行了新提交。

$ git fetch

此命令會收集有關任何已在黃金儲存函式庫中進行更改的後設資料並告知本地儲存函式庫該資訊，而不會更改本地儲存函式庫中的任何檔案或分支。

這個命令非常有用，因為它讓您知道您的分支是否落後於黃金儲存函式庫中的該分支副本：是否缺少存在於黃金儲存函式庫中的該分支副本上的提交？這讓您知道如果嘗試將更改推播到黃金儲存函式庫時是否可能遇到合併衝突。如果有人已經在黃金儲存函式庫中對相同分支進行了相同檔案的更改，除非使用 git fetch 來瞭解在該處進行了哪些更改，否則無法知道這一點。

因此，如果您想知道是否擁有某個分支上的最新更新版本或想知道是否有人已經向黃金儲存函式庫增加了任何新分支，「git fetch」是取得此資訊的一種方式。

提取（Pull）

要替換本地某個分支上的所有檔案以獲得更新版本（可能存在於黃金倉儲中的該分支副本），請切換到適當的分支並提取更改：

$ git switch login-feature
$ git pull

如果自上次執行 git pull 以來對該分支進行了任何修改，Git 會用來自黃金倉儲相同分支副本的更新檔案替換該分支上的任何本地檔案。

記住，「git pull」每次只能操作一個分支。即它只能從當前所在的分支取得黃金倉儲中的更新檔案。沒有一個明顯的理由希望一次性取得所有來自所有分餐主題領域所需編碼部分都僅來自外部修改。

  graph TD;
    A[Local Repository] --> B[Switch to Branch];
    B --> C[Fetch Updates];
    C --> D{Is Local Branch Behind?};
    D -- Yes --> E[Pull Updates];
    D -- No --> F[Continue Working];

次段落標題

小段落標題

####### 內容解密： 此圖示展示瞭如何保持本地倉儲與中央倉儲同步的一個基本工作流程。

  1. 在您的本機電腦上使用 git switch 切換到要進行工作的某個特定分餐。
  2. 接著使用 git fetch 抓取有關中央倉函式庫中該分餐最新變化內容資訊。
  3. 執行 git status 檢查確認當前分餐主題領域所需編碼部分是否落後於中央倉函式庫對該分餐主題領域所需編碼部分。
  4. 若確實存在差異則執行 git pull 動作即可把中央倉函式庫中的最新分餐主題領域所需編碼部分提取回來並更新至當前分餐主題領域所需編碼部分

然而, 以上說明僅適用於做法僅適用於單個專案, 若涉及多個專案則可以考慮將其自動化處理為批次處理

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。