前端-團隊效率-gitlab小悟

爲何要使用項目管理？

• 項目階段性，一個項目好比有開發，測試，bug修復，迭代的種種階段。甚至於不一樣區域部署不一樣的代碼。正式因爲這些階段的每一個狀態都是須要咱們嚴格控制與管理的全部纔會有git這樣的工具出現。幫助咱們管理代碼的不一樣階段與不一樣狀態。
• 成員的多數性，團隊管理的述求。團隊協做開發代碼已是常態怎麼合理的管理不一樣成員之間的不一樣權限，不一樣開發需求。都是咱們應該思考的問題？不一樣需求不一樣文件的代碼合入，同一代碼文件，不一樣需求的衝突解決？

怎麼管理項目（以gitlab爲例）

• 其實正如咱們剛纔所說的，項目管理就是管理項目的不一樣狀態。
• 這樣咱們把git項目切分紅一下內容
• master主幹用於發佈上線
• develop開發，用於測試聯調階段
• 分支別名  featrue/  加需求號即開發分支號
• 分支別名 fixout/ 加bug單號就修復bug分支
• tag標籤穩定的版本號

怎麼控制整個流程

• 每次從master拉取分支建立需求號或者bug號分支
• 需求與bug修復完成以後將代碼合入dev打包用於測試與聯調
• 測試經過後經過權限控制，將開發和修復的Bug的分支再合入master
• 如此以往反覆

注意事項

• 每次在master pull 以後保證master代碼最新能夠拉取分支，或者在遠程master上面建立最新的bug或者需求的分支在checkout 到本地
• 開發是注意  切換分支

  git checkout複製代碼

• 同時開發新需求與修復bug時能夠用緩存區

• git stash 複製代碼

• 代碼提交錯誤，想回到以前的版本

• git reset --hard 以前版本hash值複製代碼

• 遠程代碼再回退到以前狀態

• git push 分支號 --force複製代碼

重要事項再來一遍流程

遠程master 上面建立分支 保證代碼最新

git checkout -b 本地分支名 遠程分支名

開發完成 推送到遠程複製代碼

• 代碼衝突解決思路，無論需求時間，只管提交時間，後提交者合併以前人的特性需求
• 需求衝突解決？產品從新定義後，後提交者解決衝突保證需求一致
• 全部問題後處理者解決