寫給此時凌亂的你
git 現時代做前端必備的技能了。只會簡單 add? commit? 是可以臨時應付一下工作，如果進行稍微有點規模的項目，多項功能并行開發，多個bug 都必須同時修復上線，你會發現你的工作流越來越亂。
俗話說：無規矩不成方圓。所以在做開發時候有一套團隊的 git flow 還是比較重要的！ 近期我就在做這樣的事，如果你也在做，不妨一起聊聊，不同的角度會碰撞出更漂釀的火花。
進入主題：
今天重點要解決的是兩個問題： 1. 代碼分支管理? ? ? 2.?提交流程
簡單目錄：
一： 命名規范
二： 分支由來
三：?代碼推送 （ feature
四： 代碼推送 （ hotfix
五：git 命令
一：先說說我們分支命名規范：（如下圖）。 是在每個成員心中埋下一個伏筆， 以后就可以根據命名，來判斷一個分支是用來開發新功能的，還是在修改 bug。
二： 命名規范有了，接下來聊聊每一分支的由來：
? ? ? ? master? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 是石頭縫里蹦出來的
? ? ? ? develop? ????????????????????????????????是 master 的長子
? ? ? ? feature / coding01? ? ? ? ? ? ? ? ?每次新功能開發都是從由 develop 切出來的新分支
? ? ? ? hotfix / coding01? ? ? ? ? ? ? ? ? ? ?每次修改線上 bug? 都直接從 master 切一個新分支
三： 功能開發分支 （ feature / coding01 ）代碼推送流程：
? ? 本地多人開發，必須都把 topic 分支代碼合并到 feature 分支
? ? 然后推送 test / dev 進行發布測試，
? ? 測試 ok 之后，合并到 develop 分支等待上線。?
????上線之時，負責人合并 develop 代碼到 master 上線
四： Bug? 修復
修復完 Bug ，合并到 test / dev 測試
測試完成后直接推送到 master 發布
并同步給 develop ，（為了在開發新功能到時候，不用在出現老 Bug）
五： git 命令行
