剛做完一個項目並且艱難得上線，對整個項目流程和gitLab規范 有了一些心得，給新來的同學普及一下。
最先產品會寫一篇需求文檔，咱們要先看需求文檔對項目有一個大致了解，然后產品喊后端、ui、前端 一起在討論-一下項目，對項目有一個明確的認知，如果討論過程中 有咱們沒有做過功能，咱們需要調研。 ui畫完圖 咱們先看圖 想想一下項目的整個交互流程 感覺哪地方邏輯不對 可以和ui、產品一起商量，商量的時候記得叫上后端，別你們商量好了有改動 人家后端還不知道怎么回事那。 如果一些布局 你看着難受別扭，可以和ui商量 但是以ui為主，畢竟人家是 干這個的，還有剛來咱們公司 肯定會遇到沒psd圖 你沒法量 但是還需要符合規范的情況，三種方式 你要求ui出psd圖 、 還有就是 自己看《web端交互規范》和讓ui 在圖上標識距離像素。一般都是第三種，但是 由於咱們有組件庫 通常情況下 都是不用測量距離。
對項目有明確認知 就可以開始畫類圖，類關系用什么標識連接點開這個鏈接有詳細說明 https://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html ，不會畫 或者 類關系不明白的 可以問各自師傅，類圖是重中之重 真正開始寫代碼的時候 是要跟根據類圖來做的。mock在這個時候 也可以與后台制定了。
然后ui圖出完之后，咱們就可以開始畫交互時序圖了，交互時序圖要體現出 用戶的操作流程和交互效果，交互時序圖畫完要給ui看一下，哪地方的交互有問題 ui會和你說的。
圖畫完讓師傅或者組長檢查一下，然后就可以開始預演了，預演就是 你拿着這兩個圖，給團隊其他成員 去講解，尤其是 交互時序圖 需要和團隊成員達成思想一致，才算預演成功。預演通過后，需要在gitLab上自己所在項目拆分issue，
當然項目中的第一個issue 是標題：開發預演 描述：如：考試項目v1.0里程碑，預演結果--包括交互時序圖和組件的類圖，評論里面 發送 交互時序圖和類圖，開發預演issue通過了，並且組長評論了就可以關閉開發預演issue了。
創建某個issue時 需要在該issue下 評論預估時間如 /estimate 2h， h時小時、d是天數。
完成issue時 需要評論實際時間 /spend 2h 如果實際時間超出預估時間，要評論超出時長原因。
完成一個issue的流程 ：
創建issue 如上圖----評論預估完成該issue時間----准備完成某issue更改標記、選擇截至日期----代碼完成時push到該issue的分支上-----在該issue上評論實際時間--如果超時在評論超時原因--
我們開始開發功能是在dev上創建分支，功能分支 就是開發項目里面還沒有的新功能的分支，以dev-feat開頭。功能開發完之后確定沒有問題，合並到dev，如果合並到dev之后發現有問題要修復，在dev分支上建bug修復分支，以dev-fix開頭，修復完之后合並回dev，功能全部開發完畢。
完成所有issue 准備提測，提測之前需要進行代碼評審，創建代碼評審issue 如果有被審查出來的問題 描述里面把每個問題都寫上，每個問題再單獨創建一個issue,如果沒有問題，找這次評審的負責人 進行評論通過，然后將dev合並到release，由測試組同事完成合並。
dev合並release之前 需要配置好webpack，向運維要你項目的測試地址（域名），向后端要后端的服務測試地址。
合並到release 並且項目 能運行了，就算是提測成功，在測試期間 如果測試給你找到bug 他會創建issue 並把issue 指派給你，如果你發現是后端問題 你在和測試說 讓他指派給后端，領到issue后評論issue預估時間、更改結束時間，完成后需要評論實際完成時間，分支名字根據下圖來創建：
在測試環境發現的問題，在release分支上創建分支，以fix開頭，修復完合並回release 指派給測試，測試合並后，然后關閉該issue。
測試完畢后，測試會創建預上線通知，咱們前端會在預上線issue里面檢查並勾選檢查項，然后測試把relase合並到master指派給產品，產品合並后關閉上線通知issue，在線上如果找到bug 產品會創建RC里程碑，線上bug issue指向RC里程碑，在master分支上創建分支，以hotfix開頭，修復完合並回master指派給運維，運維合並后，然后關閉該issue。
項目線上沒有問題后，master合並到dev，項目負責人自己提合並請求，自己完成合並，然后將dev合並到release ，測試組同事完成合並。最后會開項目總結會要記住 開會的時候總結的幾點 ，最后會寫項目總結 寫到項目維基里。
