完整 Git 與 GitHub 使用教學：從 GitHub 建立儲存庫到分支合併 (多人協作含圖文教學)

Git 與 GitHub 是現代軟體開發不可或缺的工具，不論是個人專案或多人協作，都能透過它們管理程式碼版本。本文將以 Visual Studio Code（VSCode） 為例，帶你從零開始建立儲存庫、使用 Git 推送程式碼，以及多人協作的分支管理與合併流程，並補充 Commit Message 規範與語意化版本控制 (Semantic Versioning) 的實務建議。

一、在 GitHub 上建立儲存庫

1. 建立專案資料夾

首先，在 VSCode 中新增一個專案資料夾，作為 Git 儲存庫的基礎。

2. 開啟資料夾

開啟 VSCode，選擇剛建立的資料夾，準備進行版本控制。

3. 新增檔案

在資料夾中新增檔案，並輸入程式碼或文字內容。

新增內容

4. 發佈至 GitHub

點選 VSCode 的 「發佈至 GitHub」，並確認相關設定，即可將本地專案推送至 GitHub。

點選確定

5. 在 GitHub 查看專案

發佈完成後，可直接在 GitHub 網頁中查看剛建立的儲存庫。

6. 完成儲存庫建立

此時，專案已成功上傳至 GitHub，可以開始進行版本控制與開發。

二、Git 教學（單純使用 main 分支）

1. 新增檔案

在專案中新增檔案，命名並輸入內容。

1. 新增檔案
2. 填寫檔案名稱
3. 填寫檔案內容​

2. Git 流程

1. 暫存變更：git add .
	 查看所有待上傳的檔案。

2. 提交訊息：git commit -m "訊息"
   訊息為必填，描述本次修改內容。​

3. 推送至 GitHub：git push
	 將本地更新同步到 GitHub。

3. 確認推送

推送完成後，可在 GitHub 上看到最新程式碼。

三、建立分支與多人協作

1. 建立新分支

在 VSCode 點選 main 分支 → 建立新分支，輸入分支名稱，例如 yuna，按 Enter 建立分支。

2. 發佈分支

將新分支推送至 GitHub，即完成分支建立。

• 成功建立分支

3. 建立多個分支

假設有第二位協作者，重複以上步驟建立分支 eyelyn。

輸入分支名稱 (重複動作)

5. 確認分支數量

成功後，GitHub 上將出現三個分支：main、eyelyn、yuna。

四、分支操作與協作流程

1. 切換分支

以 eyelyn 分支為例，進行後續操作。

2. 新增檔案與提交

新增檔案，填入內容後提交至分支

3. 推送分支

點選「提交」， 將 eyelyn 分支更新同步到 GitHub。

• eyelyn 成功推送

4. 切換其他分支操作

重複相同步驟於 yuna 分支，完成多人協作推送。

• yuna 成功推送

五、分支合併教學

1. 切換到 main 分支

所有最終合併動作需在 main 分支進行。

2. 合併分支

點選「分支」->「合併」，選擇要合併的分支。

3. 合併 yuna 分支

完成後，main 分支已包含 yuna 分支的所有更新。

• main 成功合併 yuna 分支

4. 合併 eyelyn 分支

同樣操作後，main 分支即可整合所有協作者的程式碼。

• main 成功合併 eyelyn 分支

六、Git Commit Message 規範

在軟體專案開發中，通常會有多位開發者共同協作。這時候 Commit Message（提交訊息） 就扮演了非常重要的角色。它不只是程式碼的備註，更是專案維護與溝通的橋樑。好的 Commit Message 可以讓團隊快速理解變更內容，減少 Debug 時間，也能讓專案歷史更有條理。

Commit Message 的三大原則：What / Why / How

1. What（做了什麼）

描述本次提交的核心重點，例如：修正了什麼 Bug、新增了什麼功能、或是優化了效能。這通常放在 Header。

範例：

Fix typo in login form validation

2. Why（為什麼要做）

說明本次變更的動機，例如解決效能瓶頸、提升穩定性、修正某個已知問題。這些細節建議放在 Body，避免日後忘記原因。

範例：

Improve readability by renaming variables in user module

3. How（怎麼做到的）

補充方法或原則，像是使用了什麼演算法或設計模式，不必寫太細，細節可以透過程式碼本身或註解理解。

範例：

Optimize image loading by applying lazy loading strategy

Commit Message 撰寫準則

1. 標題與內容分段

• 標題（Header）簡短摘要
• 內容（Body）提供細節

範例：

Fix issue with profile update

Problem:
1. User tries to update profile with empty nickname
2. System allows saving without validation

Expected:
Nickname field must be required before saving

2. 標題限制 50 字以內，開頭大寫，不加句點（避免過長影響顯示）

3. 標題使用祈使句（命令語氣）

範例：Add validation to registration form（而不是 Added validation to registration form）

4. 內容每行不超過 72 字（避免在 Terminal 或 VSCode 顯示過長）

5. 統一用詞與風格，方便搜尋與維護

Commit Message 的結構（Conventional Commits）

推薦使用 Conventional Commits 規範，格式如下：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

• type（類型）：變更性質，例如 feat、fix、docs
• scope（範圍，可選）：影響的模組或功能
• description（描述）：一句話摘要，建議 50 字以內
• body（主體，可選）：提供背景與細節
• footer（頁腳，可選）：可寫 Breaking Change 或 Issue 編號

常見 Commit 類型

• feat：新增功能
• fix：修正錯誤
• docs：文件修改（如 README、API 文件）
• style：程式碼格式調整，不影響邏輯
• refactor：程式碼重構，不新增功能也不修 Bug
• test：新增或修改測試
• chore：雜項，如工具設定、依賴更新
• build：建置相關設定修改
• ci：CI/CD 流程或腳本調整
• perf：效能優化
• revert：回退某次提交
• hotfix：緊急修正

範例

1. feat：新增功能

feat(search): implement keyword filtering for product list

2. fix：修正錯誤

fix(profile): prevent saving profile with invalid email

3. 重大更新（Breaking Change）

feat(auth): switch to OAuth2 login flow

BREAKING CHANGE: old token-based login is no longer supported

4. docs：文件更新

docs(contributing): add commit message guidelines

4. style：程式碼風格調整

style(navbar): reformat indentation for readability

5. refactor：重構程式碼

refactor(auth): simplify token validation logic

6. test：測試相關

test(api): add unit tests for product service

7. chore：雜項工作

chore(config): update eslint rules for project

8. build：建置相關

build(deps): upgrade typescript to latest version

9. ci：CI/CD 流程

ci(pipeline): add cache step to speed up build

10. perf：效能優化

perf(image): reduce homepage image size for faster load

11. revert：回退提交

revert: remove experimental dark mode feature

12. hotfix：緊急修正

hotfix(server): fix crash caused by null pointer

Commit Message 的好處

• 提升團隊協作與溝通效率
• 版本歷史更清晰，方便追蹤問題
• 支援自動生成 Change Log
• 搭配 Semantic Versioning（語意化版本控制）自動決定版本號升級：
• • fix → PATCH
  • feat → MINOR
  • BREAKING CHANGE → MAJOR

✅ 建立一致的 Commit Message 規範，不僅讓專案更有條理，也能減少維護成本，並且為自動化流程（如 changelog 生成、版本管理）打下良好基礎。

七、Semantic Versioning

Semantic Versioning（語意化版本控制，簡稱 SemVer），它是一種常見的版本號規範，格式是：

MAJOR.MINOR.PATCH

例如：

1.4.2

代表：

• 1 → MAJOR（主要版本）
• 4 → MINOR（次要版本）
• 2 → PATCH（修補版本）

對應到 Commit Message 的規則：

1. fix → PATCH（小修小補）

• 當你用 fix 代表修正 Bug 時，就表示版本號的最後一位（PATCH）要 +1。
• 例如：1.4.2 → 1.4.3

2. feat → MINOR（新增功能）

• 當你用 feat 新增功能時，就代表版本號的第二位（MINOR）要 +1。
• 例如：1.4.3 → 1.5.0

3. BREAKING CHANGE → MAJOR（重大更新）

• 當某次提交包含「重大變更」（例如移除了舊功能或改變 API 規格，會導致相容性問題），就代表版本號的第一位（MAJOR）要 +1。
• 例如：1.5.0 → 2.0.0

簡單理解

• fix = 小修小補 → 升級 PATCH
• feat = 新功能 → 升級 MINOR
• BREAKING CHANGE = 大改動，可能會壞掉舊功能 → 升級 MAJOR

✅ 這樣做的好處是：

• 讀版本號就能知道更新的影響程度
• 使用你專案的人，可以根據版本號判斷「要不要升級」

八、小結

透過 VSCode 與 GitHub，你可以輕鬆管理專案版本，不論是單人專案或多人協作，都能有效追蹤程式碼變更與分支合併。

• Commit Message 規範 + Semantic Versioning → 提升協作效率
• 分支管理 → 多人開發安全且有序
• VSCode 整合 GitHub → 快速上手、簡單操作

建立這套流程後，專案協作將更加順暢，開發效率大幅提升。