那些年關於我們的 Pmaster 的 Git flow

Git Commit 提交規格

<類型>[可選的作用域]: <描述> [可選的正文] [可選的腳註]

<type>[<scope>]: <subject>

Type

# 主要type 
feat      : 增加新功能 
fix       : 修復bug
hotfix    : 緊急修復

# 特殊type 
docs    : 只改動了文檔相關的內容 
style   : 不影響代碼含義的改動，例如去掉空格、改變縮進、增刪分號 

例子： 新增 按鈕功能 「標籤名稱：ABC新增資料查詢」

<feat>[ABC新增資料查詢]: …

例子： 修改 按鈕功能 「標籤名稱：DEF修改資料查詢」

<fix>[DEF新增資料查詢]: …

====================================

Gitflow工作流（本地）

除了有master主分支（用於儲存正式釋出的歷史）外，還有一個作為功能整合分支的develop分支。
當初始化完成後，某個程式設計師想要開發一個性能，並不是直接從master分支上拉出新分支，而是使用develop分支作為父分支，當新功能完成後，再合併會父分支，新功能的提交併不與master分支直接互動。

維護分支(遠端)

維護分支或說是熱修復（hotfix）分支用於生成快速給產品釋出版本（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合併回master分支和develop分支（當前的釋出分支），master分支應該用新的版本號打好Tag。
為Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個釋出迴圈。 你可以把維護分支想成是一個直接在master分支上處理的臨時釋出。

Forking工作流

分散式工作流，充分利用了Git在分支和Clone上的優勢，既可以管理大團隊的開發者（developer）和接受不信任貢獻者（contributor）的提交。
這種工作流使得每個開發者都有一個服務端倉庫（此倉庫只有自己可以push，但是所有人都可以pull修改），每個程式設計師都push程式碼到自己的服務端倉庫，但不能push到正式倉庫，只有專案維護者才能push到正式倉庫，這樣專案維護者可以接受任何開發者的提交，但無需給他正式程式碼庫的寫許可權。
這種工作流適合網上開源社群的開源專案，大家統一對專案做貢獻，但是有一個人或一個團隊作為開發者來管理專案，所有的貢獻者的程式碼由開發者稽核，其功能完善之後再由開發者push到正式倉庫中。

功能開發前，先刷新本地端的倉儲，確定目前的版本為最新，從 DEV 切出分支

git pull 遠端路徑名稱 分支名稱

ex: git pull origin DEV

開發完合併 推上去 分支後，切換畫面到
Pull requests > New pull request > [目標分支 <- 推送分支]

舉個例子

目前想做個小功能 先更新 dev 以確保是從最新的 dev 拉出來的分支

git pull origin dev

然後從 dev 拉出分支

git checkout -b feat/happy_ruby-Wei

當功能完成後把開發的分支推上去

git push origin feat/happy_ruby-Wei

然後再 Github 上用推上去的分支對 dev 發出 PR 就完成了