## 開發流程 master：線上穩定版本（所有功能都是穩定的） dev：新功能測試版本（每個功能都是基本完整的，可用的，但可能不穩定，屬于測試階段） xiak-monitor-pay：功能開發分支（開發中） ... ---- ### 線上緊急問題修復 直接從master 拉一個 fix-bug 分支出來修復，測試完畢后，然后合并到master以解決緊急問題 然后不要忘了，dev 和 功能開發分支 要拉 master 的更新 ---- ### git開發流程/規則 **master：主分支，線上生產環境代碼** **dev：開發測試分支，測試環境代碼，用于內部測試** 1. master和dev上從不直接修改代碼，只接受合并 2. 開發新功能和迭代永遠只在master拉分支出來的功能分支上進行 3. 開發過程中，經常從master往自己的功能分支合并，越頻繁越好（重復三遍） 4. 功能開發完畢（最新的master往上合過并通過自測才算是開發完畢），先合到dev上進行測試 5. 測試(內側)沒問題就可以往master上合并上線 6. 如果一個功能最初是從某個功能分支中出來的，那么只要涉及該功能的更新，就需要一直維護該分支，沒有特殊情況不要拋棄它而去建立新的迭代分支，確保不要出現一個功能分散在多個分支中 7. 建立功能分支時功能要確定，不能模棱兩可，一個功能只能在一個分支中，確保該功能的整個生命周期都由該分支來維護和迭代。 8. 功能分支只有測試通過，需要直接上線時才需要往master上合并 9. 經常從master往自己所開發的功能分支上合并是好習慣 10. dev只能接受合并，永遠不能往其他任何分支合并，切記！ 11. git的合并操作是：往當前所在的分支合，一定不要看錯了當前所在分支（命令行中可能沒實時顯示，按下回車或查看當前所在分支） 12. 功能分支的粒度要盡量小，不要把很多功能都放在一個功能分支中，盡量一個小功能一個功能分支 13. 處于開發的功能分支之間不能有任何肢體接觸 14. 處于開發的功能分支是不完備的，經常有coding...這樣臨時保存代碼的提交，而dev和master上，決不允許出現這樣的提交（HEAD） 15. 有時候需要單獨測試某個功能分支，dev.abc.com環境切換為需測試的分支即可 16. 每次開始寫代碼前，不要忘記git pull拉代碼，并且開發過程中需要經常拉代碼，越頻繁越好，因為即使某一個功能分支也往往是由多人同時開發的。 17. 功能開發完畢后合并到master分支上線時別忘記了檢查開發時的一些為開發環境所作的特定配置修改，如一些硬編碼的配置參數，要仔細檢查，如預定功能的預定限額(硬編碼)，開發時往往為了方便會調整這些值，但是正式上線時一定要修改為正式環境的配置再上線。否則如果把開發/測試環境的配置帶到線上了就會造成嚴重的后果。 嚴格遵守以上規則，如果你發現你想做的操作不包含在以上規則中，則一定不要做！ ---- ### 其他 當然如果時間過去很久，都差不多忘記當初的分支了，也可以拋棄它再新建分支 ---- **速記：** master：可以把我合到任何地方，但別輕易合并到我身上。 dev：要測試的往我這兒合并，但不要讓我合并到你身上，否則你就完了。 上線：上線時檢查所有開發環境的配置(硬編碼參數等)，確保線上除了邏輯代碼正常外所有軟硬配置也要正確。 各功能分支間：盡量不要有交流，實在想交流的話，彼此得要做好充分的準備，溝通協商好（這意味著兩個功能有不可避免的耦合）；如果上線了，要交流通過master。 ---- last update：2019-8-8 14:22:53