2024年09月26日玄貓（BlackCat）

從初始化到分支協作的 Git 實戰指南

本文闡述 Git 版本控制的核心實務流程，從初始化本地與遠端倉庫、執行首次提交與推送到進階的團隊協作。內容涵蓋克隆專案、同步程式碼更新，並詳解如何利用分支進行隔離開發與合併，為開發者建立穩固的協作基礎。

軟體開發版本控制

Git Azure DevOps 分支管理版本控制團隊協作 Pull Request

在現代軟體開發中，版本控制系統是確保專案穩定性與團隊協作效率的基石。Git 作為分散式版本控制的業界標準，提供了一套管理複雜開發任務的系統化方法。本篇將從建立全新專案開始，逐步解析其從初始化、提交推送到分支管理的核心機制。透過對 clone、pull 與 branch 等指令的實踐，闡明 Git 如何透過隔離開發與有序合併，來支持敏捷且可靠的協作模式，為高效的程式碼管理奠定基礎。

實戰演練：從零開始建立 Git 專案與協作

本節將透過一個實際案例，引導您完成從建立遠端 Git 倉庫到進行首次提交與推送的全過程，讓您親身體驗 Git 的基本工作流程。我們將以 Azure DevOps 平台作為遠端倉庫的託管服務。

建立與配置遠端 Git 倉庫

首先，我們需要在 Azure DevOps 上創建一個新的專案，並在此專案下建立一個 Git 倉庫。

創建 Azure DevOps 專案: 登入 Azure DevOps 後，創建一個新的專案。在創建過程中，選擇「Git」作為版本控制類型。
導覽至 Azure Repos: 專案創建完成後，在左側導覽菜單中找到並點擊「Azure Repos」服務。
初始化倉庫: Azure DevOps 通常會為新專案自動創建一個同名的預設倉庫。如果倉庫是空的，我們需要將其初始化。

初始化本地倉庫與遠端連接

接下來，我們將在本地機器上準備開發環境，並將本地倉庫與遠端倉庫建立連接。

創建本地專案目錄: 在您的電腦上創建一個新的目錄，用於存放專案的程式碼。例如，創建一個名為 bookProject 的目錄。
初始化本地 Git 倉庫: 進入 bookProject 目錄，然後執行 git init 命令來初始化一個新的本地 Git 倉庫。
```
cd bookProject
git init
```
此命令會在目錄下創建一個隱藏的 .git 子目錄，標誌著該目錄已成為一個 Git 倉庫。
獲取遠端倉庫 URL: 回到 Azure DevOps 的倉庫頁面，找到並複製該倉庫的 URL。這個 URL 通常是 HTTPS 或 SSH 格式的連結。
關聯本地與遠端倉庫: 在本地的 bookProject 目錄中，執行 git remote add 命令，將本地倉庫與遠端倉庫關聯起來，並為遠端倉庫指定一個別名（通常是 origin）。
```
git remote add origin <遠端倉庫的URL>
```
例如：
```
git remote add origin https://dev.azure.com/your-organization/your-project/_git/bookProject
```
現在，您的本地倉庫已經與 Azure DevOps 上的遠端倉庫成功連接。

首次提交與推送程式碼

準備工作就緒後，我們開始編寫程式碼並將其提交到倉庫。

創建並編輯文件: 在 bookProject 目錄中，創建一個名為 Readme.md 的文件，並添加一些示例文本。
將文件添加到暫存區: 使用 git add 命令將 Readme.md 文件添加到 Git 的暫存區，準備進行提交。
```
git add Readme.md
```
您也可以使用 git status 命令來查看當前倉庫的狀態，確認 Readme.md 已被識別為待提交的新增文件。
創建本地提交: 使用 git commit 命令創建一個本地提交，並附帶描述性的訊息。
```
git commit -m "Add initial Readme.md file"
```
這個提交將 Readme.md 的變更記錄在本地倉庫中。
推送變更到遠端倉庫: 最後，使用 git push 命令將本地的提交推送到遠端倉庫。
```
git push origin main
```
（請將 main 替換為您實際使用的預設分支名稱，例如 master）。首次推送時，系統可能會要求您進行身份驗證（輸入 Azure DevOps 的用戶名和密碼或個人訪問令牌）。成功驗證後，您的本地變更將被上傳到 Azure DevOps 上的遠端倉庫。

視覺化專案初始化與首次提交流程

以下圖示總結了從創建遠端倉庫到完成首次提交與推送的整個流程。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

start

component "Remote Repository Setup" {
  :Create Azure DevOps Project;
  :Initialize Azure Repos Repository;
}

component "Local Repository Setup" {
  :Create Local Project Directory;
  :Initialize Local Git Repo (`git init`);
  :Get Remote Repository URL;
  :Add Remote Origin (`git remote add origin <URL>`);
}

component "Code Development & Commit" {
  :Create/Modify Files (e.g., Readme.md);
  :Stage Changes (`git add .`);
  :Create Local Commit (`git commit -m "..."`);
}

component "Synchronization" {
  :Push to Remote (`git push origin <branch>`);
}

Remote Repository Setup --> Local Repository Setup : Establish Connection
Local Repository Setup --> Code Development & Commit : Prepare for Work
Code Development & Commit --> Synchronization : Share Changes

stop

@enduml

看圖說話：

此圖示詳細描繪了從零開始建立一個 Git 專案並完成首次協作提交的完整流程。首先，「Remote Repository Setup」階段涵蓋了在 Azure DevOps 上創建專案和初始化遠端倉庫的步驟。接著，「Local Repository Setup」階段展示了如何在本地創建專案目錄，使用 git init 初始化本地倉庫，並通過 git remote add 命令將本地倉庫與遠端倉庫（指定為 origin）建立連接。

完成倉庫設置後，「Code Development & Commit」階段開始實際的開發工作。這包括創建或修改文件，使用 git add 命令將變更暫存，然後通過 git commit 命令將這些變更記錄為本地提交。最後，「Synchronization」階段是將本地的提交通過 git push 命令發送到遠端倉庫，從而實現與團隊的共享。圖示中的箭頭清晰地展示了各個階段之間的順序和依賴關係，為初學者提供了一個直觀的操作指南。

Git 協作進階：克隆、更新與分支隔離

在完成首次提交與推送後，我們將進一步探討團隊成員如何協同工作，包括如何獲取遠端倉庫的副本、同步最新的程式碼變更，以及利用分支機制隔離開發，確保主線程式碼的穩定性。

克隆遠端倉庫

當一個新成員加入專案，或需要在新環境中獲取專案程式碼時，他們會執行「克隆」(clone) 操作。這會將遠端倉庫的完整歷史記錄複製到本地。

執行克隆命令: 在終端機中執行以下命令，替換 <repository url> 為實際的遠端倉庫 URL。
```
git clone <repository url>
```
這個命令會自動執行以下操作：
- 在當前目錄下創建一個與倉庫同名的新目錄。
- 在該新目錄中初始化一個本地 Git 倉庫。
- 下載遠端倉庫的所有文件和版本歷史。
- 自動配置本地倉庫與遠端倉庫的連接（通常別名為 origin）。
克隆完成後，開發者即可在此本地倉庫中進行開發、修改和提交。

更新本地程式碼

在團隊協作中，遠端倉庫會不斷接收成員推送的更新。因此，開發者需要定期將這些變更同步到本地倉庫。

推送本地變更: 當開發者在本地完成程式碼修改、暫存並提交後，需要將這些本地提交推送到遠端倉庫，以便其他成員獲取。
```
# 假設已完成 git add 和 git commit
git push origin <分支名稱>
```
例如，將 main 分支的變更推送到 origin：
```
git push origin main
```
拉取遠端更新: 當需要獲取遠端倉庫的最新變更時，執行 git pull 命令。
```
git pull origin <分支名稱>
```
例如，從 origin 的 main 分支拉取更新：
```
git pull origin main
```
此命令會從遠端獲取最新提交，並嘗試將其合併到當前的本地分支。如果合併過程中出現衝突，則需要手動解決。
- git fetch 的作用: 如果您只想下載遠端變更但暫不合併，可以使用 git fetch。它會更新遠端分支的引用，但不會修改您的本地工作目錄或當前分支。之後，您可以選擇手動合併（git merge）或執行其他操作。

利用分支隔離開發

在開發應用程式時，為了避免影響正在運行的穩定程式碼，我們需要一種機制來隔離正在進行的開發工作。Git 的分支功能正是為此而設計。

分支工作流程:

創建新分支: 從一個現有分支（例如 main 或 develop）創建一個新的分支，用於開發特定功能或進行實驗。
隔離開發: 在新創建的分支上進行程式碼修改、添加和提交。這些變更僅存在於該分支上，不會影響原始分支。
程式碼審查 (Pull Request): 在團隊開發中，當一個分支上的工作完成後，通常會創建一個「合併請求」(Pull Request, PR)。這是一個讓其他團隊成員審查變更、提供反饋並最終批准合併的機制。
合併變更: 一旦變更被批准，就可以將該分支的程式碼合併回原始分支（例如，將功能分支合併回 main 或 develop）。

分支的視覺化表示:

在 Git 中，分支可以被視為指向特定提交的指標。當您在一個分支上進行提交時，該分支的指標會向前移動，指向新的提交。不同分支可以獨立發展，直到它們被合併。

實踐：創建與合併功能分支

假設我們需要在 main 分支的基礎上創建一個名為 Feature1 的分支，並在此分支上進行一些變更。

創建並切換到新分支:
```
git checkout -b Feature1
```
這個命令等同於先執行 git branch Feature1 再執行 git checkout Feature1。
進行程式碼變更: 在 Feature1 分支上修改現有文件或添加新文件，並使用 git add 和 git commit 將變更提交到 Feature1 分支。
合併回主分支: 完成 Feature1 分支的開發後，切換回 main 分支，然後執行合併操作。
```
git checkout main
git merge Feature1
```
如果沒有衝突，Feature1 分支的變更將被整合到 main 分支。

視覺化分支與合併概念

以下圖示展示了分支的創建、開發和合併過程。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

start

component "Branching Workflow" {
  node "Branch A (e.g., main)" as A
  node "Branch B (e.g., Feature1)" as B

  A --> B : git branch Feature1 (from A)
  B --> B : Make changes on Branch B (commits)
  A --> A : Make changes on Branch A (commits)

  B --> A : git merge B into A
}

stop

@enduml

看圖說話：

此圖示直觀地展示了 Git 分支的創建與合併過程。圖中，「Branch A」（例如，代表 main 分支）是初始分支。通過 git branch Feature1 命令，可以從「Branch A」創建出一個新的分支「Branch B」（例如，代表 Feature1 分支）。

在創建後，「Branch B」獨立於「Branch A」存在。開發者可以在「Branch B」上進行一系列的程式碼修改和提交（圖示中的「Make changes on Branch B (commits)」）。同時，「Branch A」也可能會有獨立的開發活動（圖示中的「Make changes on Branch A (commits)」）。

當「Branch B」上的開發任務完成後，可以通過 git merge Feature1 命令將「Branch B」的變更合併回「Branch A」（圖示中的「git merge B into A」）。完成合併後，「Branch A」就包含了「Branch B」上的所有變更。這個流程清晰地體現了 Git 如何通過分支機制實現開發的隔離與整合，是團隊協作中處理不同開發任務的基礎。

結論

縱觀現代技術專案的複雜性與團隊協作需求，Git 已不僅是單純的版本控制工具，更深層地體現了一套完整的協作哲學與治理框架。若將其與傳統管理方法對比，Git 的分支（branch）與合併（merge）機制，實質上為組織提供了一種可控的創新實驗場域，允許團隊在不干擾主線穩定性的前提下進行探索。然而，導入此工具的真正挑戰，並非技術操作的學習曲線，而是如何將這種具備紀律性與可追溯性的協作文化，從少數技術核心擴散至整個團隊心態。從 pull 的自動整合到 fetch 的審慎檢視，每個指令的選擇都反映了團隊對風險與效率的權衡，這正是管理者需介入引導的決策點。

展望未來，源自版本控制的思維模式——例如「分支用於探索、主線保持穩定、合併需經審查」——將不僅限於軟體開發，更有潛力成為跨領域知識工作者管理複雜專案的通用心法。這種結構化的協作語言，將是提升團隊集體智慧與交付品質的關鍵基礎建設。

因此，高階管理者應將視角從「要求團隊使用工具」提升至「建構基於版本控制原則的協作系統」。真正的價值，在於將這套流程內化為組織的風險控管與創新賦能機制，而不僅是工程師的日常指令。