那些年關於我們的 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程式碼到自己的服務端...