現在回頭看發現 整個專案的git flow 亂七八糟，commit 沒有太多參考價值

開新branch分支，完成功能後再合併回主支

舉例

開發線上支付功能，這時候開一個 onlinePay branch，中間的雜七雜八的commit都在這個branch。

等完成功能再合併回mater主分支，這時候主master就只會有一個merge commit，不會有亂七八糟的commit log紀錄，假如中間線上專案遇到BUG，也是一樣方式處理。

其實這跟在Github社群中修改開源專案方式一樣，不可能讓你隨便動主分支的資料，所以貢獻者會先fork專案，接著開一個分支在此新專案

修改完後在 pull reqeust 請求原專案作者檢查、確認後merge到主分支

參考Git Flow
https://gitbook.tw/chapters/gitflow/why-need-git-flow.html
https://medium.com/kuma%E8%80%81%E5%B8%AB%E7%9A%84%E8%BB%9F%E9%AB%94%E5%B7%A5%E7%A8%8B%E6%95%99%E5%AE%A4/%E5%9F%BA%E7%A4%8E-git-flow-%E5%B7%A5%E4%BD%9C%E6%B3%95-fa50b1dddc4f

簡化並整理一下你的問題：

1. 建議 commit 的時機與內容為何？
2. commit 容易出現不屬於該 commit 的內容，該怎麼解決
3. 怎樣的 commit 才具備參考的價值？
4. 規範開發流程有辦法解決嗎？
5. 現在還能做什麼補救？

首先，版控的目的，是記錄讓大家看的歷史，所以要記錄到大家可以輕鬆讀，才有意義。

這個前提先建立好後，3 的答案就很明確了：能輕鬆讀的 commit 才具備參考價值。有道是「少即是多」，能用簡短的 comment 精確描述內容，即是一個好的 commit。

因此 1 的建議是，如果一行就能精確說明 commit 內容的話，這時就是絕佳的 commit 時機與內容，這也是 4 的規範可以納入思考的方向；反之，代表目前的內容太過複雜，需要分多次 commit，這也是 2 的解決方法。至於舉例是困難的，因為如何「精確說明」會跟需求和程式碼有直接關係。

Commit 的精鍊是需要訓練的，也就是會越做越好，所以 5 的建議是：都不要動，未來才會知道哪個做法才是比較符合團隊的。