大部分前端的工作模式
- 協同開發,大家都git clone 遠程倉庫到本地
- 從master上切自己的本地分支進行開發
- 若遇到線上緊急bug需要修復,從master上切一個bug-fixed分支 修復bug后 把此分支merge到master 緊急發布生產
- 然后把bug-fixed的merge到dev分支上 以保持dev和master的同步
- 測試階段,將自己的本地分支merge到dev分支
- 測試完畢,上線階段的時候再把自己的本地分支merge到master分支發生產
之前所在的公司幾乎都是上述這種工作模式,其優點就是傻瓜式操作,簡單易上手
其弊端就是大部分人commit之前不喜歡pull下最新代碼 導致會有merge commit,經常也會遇到沖突,然后git樹不是線性的
現公司要求的工作模式:
以sourcetree舉例
- 協同開發,大家都git clone 遠程倉庫到本地
- 從master上切feature分支作為本期需求的開發分支
- 所有開發人員從feature分支上切自己的本地分支進行開發 以姓名-模塊的形式命名分支
- 每天推送代碼之前,先切到feature分支上 git pull最新的代碼 並且是用變基代替合並 保證自己本地的feature是最新的代碼
- 切回到自己的開發分支,然后右擊feature分支 選擇將當前變更變基到feature分支上 有沖突則解決沖突
- 將自己的分支推送到遠程
- 在gitlab上發起merge request 將自己的分支合並到feature分支上並且指定review的人員 Review通過后由其merge
- 如果線上有緊急bug修復,從master上切bug-fixed分支 修復bug后發起merge request至master 並設定相關Review人，Review通過后，將對應commit cherry-pick至Master分支
git命令行的話則是如下操作
- 克隆遠程倉庫到本地: git clone 遠程倉庫地址
- 此時本地默認只有master分支 需要切換到遠程的featureA分支: git checkout -b featureA origin/featureA
- 從featureA上切自己的分支開發: git checkout -b 姓名_模塊
- 提交代碼:git add. + git commit -m '描述' 兩連
- 在自己的開發分支git fetch 獲取遠端所有更新
- git rebase origin/featureA 本地開發分支上所有的變更變基最新的featureA上
- git push -f origin 姓名_模塊
- 在gitlab上創建merge request
總結
現公司的工作模式有以下幾點是我之前沒有遇到過的 更加的規范,有利於多人協同開發的工作模式 繼續加油~~
git rebase
變基rebase這個操作說白了就是，重新選定當前提交的根節點
這個操作會把整個本地分支移動到feature分支的后面，有效地把所有feature分支上新的提交並入過來 就能保證git樹的線性了
merge request
以前我們習慣於自己在本地進行將開發分支和功能分支進行合並 有沖突解決沖突 然后推送到遠端
merge request的作用其實就是多了一層review 由指定的人員review之后再merge
cherry-pick
復制一個特定的提交到當前分支 避免重復勞動 也不用合分支
git cherry-pick 4c805e2