1. 版本控制與協作流程（Git 工作流、分支管理、合并沖突）

• 雖然 Git 用得多，但“rebase vs. merge”、如何解決沖突、如何編寫規范的 commit message、如何維護主干的穩定性，都需要一段時間才能形成體系化的理解。

摘要

在日常團隊協作開發中，Git 是不可或缺的工具。然而，隨著項目復雜度的提升，如何在多人協作環境下保持主干穩定性、合理地管理分支、解決合并沖突以及編寫規范的提交信息，成為擺在開發者面前的現實問題。本文將通過一個典型的開發場景展開，從環境配置到工作流設計，再到沖突解決和最佳實踐，逐步構建一個系統化的理解。

@[toc]

---

1 開發場景介紹

在一個中大型的微服務項目中，團隊成員往往并行開發多個功能。此時問題頻頻出現：

• A 開發者和 B 開發者同時修改了 user_service 的接口文件，最終提交時發生沖突。
• 團隊對 git merge 和 git rebase 的使用意見不統一，導致提交歷史混亂。
• 主干分支偶爾出現“壞代碼”，影響了后續 CI/CD 部署。

“Git 本身并不復雜，復雜的是人和團隊如何用好它。”

---

2 開發環境說明

下表展示了本文的實驗環境：

工具/環境	版本	說明
Git	2.42+	核心版本控制工具
IDE	VSCode / IntelliJ	提供 Git 插件支持
CI/CD	GitHub Actions / Jenkins	自動化測試與部署
操作系統	Ubuntu 22.04 / macOS	開發環境

---

3 Git 工作流設計

一個合理的工作流能減少 70% 的沖突。常見的兩種模式：

3.1 Git Flow

• master：生產穩定分支
• develop：開發主干
• feature/*：新功能開發
• release/*：發布準備
• hotfix/*：緊急修復

3.2 GitHub Flow

• 只有一個長期存在的 main 分支
• 每個功能分支從 main 拉出
• 合并必須通過 PR 和 Review

---

4 rebase vs. merge

在合并分支時，rebase 與 merge 經常讓人困惑：

• merge 保留分支歷史，但會產生“叉路”提交。
• rebase 重寫提交歷史，讓歷史更線性，但需要謹慎使用。

建議：公共分支用 merge，個人分支可用 rebase 整理提交歷史。

---

5 沖突解決實戰

沖突不可避免，但解決方式可控。

場景：

• dev 分支中修改了 api/user.js 第 10 行返回 JSON。
• feature/profile 分支中在同一行修改了字段結構。

解決步驟：

1. 執行 git pull origin dev → 發生沖突
2. 使用 git status 查看沖突文件
3. 打開文件，手動修改：

<<<<<<< dev
return { id: user.id, name: user.name };
=======
return { id: user.id, name: user.name, avatar: user.avatar };
>>>>>>> feature/profile

4. 修改為合并后的最終版本：

return { id: user.id, name: user.name, avatar: user.avatar };

5. 執行 git add . && git rebase --continue

---

6 編寫規范的 Commit Message

一個清晰的提交信息，有助于后續排查問題與代碼回顧。

常見規范（Angular 規范）：

<type>(scope): <subject>

示例：

feat(user): add avatar support
fix(api): resolve null pointer exception
docs(readme): update installation guide

提示：使用 commitlint + husky 可以在提交階段自動校驗信息格式。

---

7 保持主干穩定性的最佳實踐

• 所有提交必須通過 CI/CD 測試 才能合并到主干。
• 使用 保護分支（Protected Branch） 功能，避免直接推送到 main。
• 嚴格執行 Code Review，至少兩人通過才能合并。

---

8 總結

Git 本身功能強大，但如果沒有清晰的協作流程和規范，項目就會陷入“沖突地獄”。
本文從開發環境、工作流設計、rebase 與 merge 的取舍，到沖突解決與提交規范，給出了一個系統化的實踐指南。

未來團隊可以繼續優化：

• 引入 Git Hooks 自動檢查提交代碼質量
• 借助 GitOps 將 Git 作為運維的唯一可信源

---