簡介
今天來總結一下在實際項目開發中使用Git工作流的最佳實踐，項目使用gitlab作為版本控制。比較適合小型或者中型的多人合作，快速迭代開發的項目。
分支
首先來介紹一下分支的設計。一般分為這么幾類分支:
- master
- develop
- feature分支
- bug分支
master為主分支，為protected分支，只允許其他分支的merge，不允許直接push代碼。
develop為開發的主分支，feature和bug分支提交merge request到develop。
在開發中，針對每個功能開一個feature分支進行開發，命名可以為 [feature/xxx]，開發完成后提交merge request，合并到develop分支。
針對開發中遇到的bug，新開一個bug分支，修復后，也提交merge request到develop分支。
開發流程
注意點：
- 規范的commit message格式
- 拉取develop分支代碼的時候使用rebase而不是merge
- 使用rebase整理個人feature分支的commit
- 開merge request進行code review
首先應該制定一個commit的message的規范和格式，要求每次提交的commit message清晰。具體的格式可以根據團隊的習慣制定，只需要能表述清晰即可。
對于個人的feature分支，在準備提交MR合并進develop之前，應該用git rebase來整理自己的commit，使得邏輯清楚。同時可以避免產生[merge branch develop ***]這樣的commit。
具體操作如下：
// 在feature/xxx分支上進行開發，并進行了一些提交，此時要合并到develop分支
// 首先用rebase的方式拉取develop分支代碼
git pull origin develop --rebase
// 如果有conflict，修復conflict，然后
git rebase --continue
// 如果有多個conflict，不同于直接merge，使用rebase可能需要多次解決conflict，并多次執行git rebase --continue
// 如果有需要使用
git rebase -i
// 來整理自己的commit，可以用來將一些小的commit合并，以及修改優化自己的commit message
// 然后push到feature/xxx分支，由于rebase，可能會導致本地與遠端的history不一致，使用force強制重寫遠端分支
git push --force
// 最后在gitlab上開一個merge request到develop分支
// 團隊其他成員review這個MR，并提出修改意見，然后根據修改意見，優化原來的代碼，把存在問題的地方改掉，知道最后沒有問題，將feature/xxx分支合并到develop
部署
master分支永遠是穩定的版本，在master分支上，可以使用CI工具進行持續集成和自動部署。develop分支每次完成部分功能就可以merge到master，使得項目可以快速高效的迭代開發。
rebase or merge？
在個人分支上，推薦只使用rebase而不是merge，因為rebase可以讓你的提交看起來意義明確，并且沒有無意義的merge其他分支的commit。
而在主分支上， 只允許merge操作，從而保證主分支的commit歷史的完整性。在多人開發的主分支上進行rebase操作是一件很危險的行為，可能會導致其他成員的history與主分支不一致。
總結
個人認為，現在這樣的git工作流可以很好的適應小團隊的項目快速迭代開發，使得項目網絡清晰明了。但是當項目變得復雜的時候，可能需要更復雜的控制，這部分沒有什么實踐的經驗就不談了。如果有不嚴謹的地方請指出。
