# Git 專案管理
Elantris

[TOC]

---

## 前言
版本控制除了方便回顧每個檔案的歷史紀錄以外最適合用在多人協作時追蹤彼此的進度，於是「如何管理 Git 專案」便是一大課題。最廣為知名的一個模型 Git Flow 規範了每個 branch 代表的含義以及彼此的交互關係，同時兼顧多人非同步開發與正式部署上線的版本。

## Git Flow
簡介一下 git flow 模型定義的 branch：

- main (master)：正式部署上線用的最穩定版本
- develop：開發中的版本
- feature：撰寫新功能時從 develop 分支出去，寫完後再合併回 develop
- hotfix：當部屬後發現問題時以 main 為起點，修完後同時合併回 main 以及 develop
- release：當 develop 發展穩定後，在正式部署前開一個預訂穩定版本做測試用，測試沒問題再合併到 main，如果中途有修改時再同步回 devleop

## 簡化後的流程
原版的模型對於小規模的專案來說還是有點太繁重了，作為一名管理者可以適時的簡化一些流程讓團隊運作更順暢。如果團隊成員對於 git 使用還不太熟悉的話建議使用 GUI 幫助理解整體狀況，千萬不要假裝自己很會導致犯下更多錯誤造成團隊困擾，例如把不該被追蹤的機密檔案推上去或處理合併時不小心覆蓋掉別人辛苦的成果等等。

### Branch
我通常只保留最重要的三個 branch：

- main：穩定版本
- develop：開發中、測試用版本
- feature：各個獨立開發中的功能

對於新創小團隊來說產品服務的迭代更新頻率雖然較高，但實際上協作開發的人數並不多，理論上團隊中的每個人都能同步到彼此的工作進度、不會在正式上線前突然又加入新功能。這時 release 的功能性質和 develop 太過於相似可以省略，而又因為測試完到部署之間不會有新的變化所以 hotfix 可以直接在 develop 上完成再合併到 main 即可。

### Review
為了確保團隊中每個成員的產出能夠符合一致的標準，在建立專案初期就應訂下一些開發規則，例如程式碼排版、linter 規則、style guide、design pattern。每一年各個社群都會有人提出各式各樣的 best pratice，用文章的形式推廣自己喜歡的流派，偶爾參考一下不同團隊的寫法以及探討每一個選擇的理由有助於培養自己的開發習慣。

加入 review 機制後的實際開發流程：

1. 開發新的功能時從當下 develop 各自開獨立的 feature branch
2. 開發完要合併回 develop 前需要經過其他人 review，在 GitHub 上就用 pull request
3. review 時注重的幾個要點，如果有一項沒有符合就退回請對方重新修改
1. 檢查變數命名、程式碼可讀性
2. 檢查程式邏輯是否有符合商業需求
3. 檢查程式運作的效率
4. 檢查 formatter、linter 規範以外的寫法規則