一直以來公司都是svn來進(jìn)行版本控制，雖然svn的版本控制也可以說滿足公司的日常需求，但是作為使用git的人來說，我真的裂墻安利git。

無論是版本控制，分支管理，還是存儲都更加合理，更加快速。

為了以后升職加薪，為了早日實(shí)現(xiàn)git稱霸天下的夢想，為了世界和平，我要琢磨一篇git工作流程，以備不時(shí)之需。

image.png

希望解決的問題

1. 目前的開發(fā)都是在主分支上，沒有分支的概念之說，容易造成沖突?。?！
2. 沒有代碼review的機(jī)制
3. 每當(dāng)開發(fā)同一個(gè)產(chǎn)品的另外版本的時(shí)候，只能重新復(fù)制一個(gè)出來，無法統(tǒng)一管理

工作流程思考

分支管理：每一個(gè)項(xiàng)目都要創(chuàng)建test, develop分支。

master 是生產(chǎn)環(huán)境，當(dāng)完成日常的feature開發(fā)，可以merge到master分支
test分支上的代碼用于日常測試，可能會存在bug
develop是代碼已經(jīng)測試并且已經(jīng)部署到開發(fā)調(diào)試環(huán)境

1. 新創(chuàng)建個(gè)分支。
   如果是新的開發(fā)需求分支命名為 開發(fā)人員-feat-模塊名字，如git checkout -b may-feat-login
   如果是修改bug,分支命名為開發(fā)人員-fix-模塊名字,如git checkout -b may-fix-may-fix-login
2. 修改代碼,提交代碼
   git commit調(diào)出編輯器，寫多行信息

<type>(<scope>): <subject> // 必須

type: 提交類別
feat：新功能（feature）
fix：修補(bǔ)bug/ docs：文檔（documentation）
style： 格式（不影響代碼運(yùn)行的變動）
refactor：重構(gòu)（即不是新增功能，也不是修改bug的代碼變動）
test：增加測試
chore：構(gòu)建過程或輔助工具的變動

image.png

npm install -g commitizen  // 安裝
commitizen init cz-conventional-changelog --save --save-exact // 項(xiàng)目里運(yùn)行
git commit 換成 git cz

為了commit的規(guī)范，自己也搜索了一圈，發(fā)現(xiàn)很多人在提交的時(shí)候使用Emoji標(biāo)簽，也是非常棒的
emoji emoji 代碼 commit 說明
?? (慶祝) :tada: 初次提交
? (火花) :sparkles: 引入新功能
?? (書簽) :bookmark: 發(fā)行/版本標(biāo)簽
?? (bug) :bug: 修復(fù) bug
?? (急救車) :ambulance: 重要補(bǔ)丁
?? (地球) :globe_with_meridians: 國際化與本地化
?? (口紅) :lipstick: 更新 UI 和樣式文件
?? (警車燈) :rotating_light: 移除 linter 警告
?? (扳手) :wrench: 修改配置文件
? (加號) :heavy_plus_sign: 增加一個(gè)依賴
? (減號) :heavy_minus_sign: 減少一個(gè)依賴
?? (上升箭頭) :arrow_up: 升級依賴
?? (下降箭頭) :arrow_down: 降級依賴
?? (閃電)
?? (賽馬) :zap:
:racehorse: 提升性能
?? (上升趨勢圖) :chart_with_upwards_trend: 添加分析或跟蹤代碼
?? (火箭) :rocket: 部署功能
? (白色復(fù)選框) :white_check_mark: 增加測試
?? (備忘錄) :memo: 撰寫文檔
?? (錘子) :hammer: 重大重構(gòu)
?? (調(diào)色板) :art: 改進(jìn)代碼結(jié)構(gòu)/代碼格式
?? (火焰) :fire: 移除代碼或文件
?? (鉛筆) :pencil2: 修復(fù) typo
?? (施工) :construction: 工作進(jìn)行中
?? (工人) :construction_worker: 添加 CI 構(gòu)建系統(tǒng)
?? (綠心) :green_heart: 修復(fù) CI 構(gòu)建問題
?? (鎖) :lock: 修復(fù)安全問題
?? (鯨魚) :whale: Docker 相關(guān)工作
?? (蘋果) :apple: 修復(fù) macOS 下的問題
?? (企鵝) :penguin: 修復(fù) Linux 下的問題
?? (旗幟) :checked_flag: 修復(fù) Windows 下的問題

3. code reivew
   目前主流的code review 工具 Phabricator
   在commit中引入code review的機(jī)制，如果無法通過審核，需要重新修改代碼，繼續(xù)提交。直到通過提交
   最后再 git push

4. 合并分支，將自己的產(chǎn)出may-feat-login分支的代碼合并到master分支，再刪除分支

git checkout master // 切換到master分支
git rebase may-feat-login  
// 如果遇到?jīng)_突，解決沖突
git add . // 解決沖突的代碼重新加入緩存
git rebase  --continue 
git checkout -d may-feat-login // 刪除分支

5. 當(dāng)遇到產(chǎn)品其他版本的開發(fā)的時(shí)候
   比如遇到產(chǎn)品專門為ios 手機(jī)定制的一塊新功能的時(shí)候
   創(chuàng)建新分支，命名為 master-ios

git checkout -b master-ios

6. 當(dāng)有其他通用的內(nèi)容需要在多個(gè)版本代碼修改的時(shí)候，
   比如對分支 may-feat-dateTime的功能，需求在master 和 master-ios上都能更新到

git checkout master
git rebase may-feat-dateTime
// 解決沖突
git rebase  --continue 

git checkout master-ios
git rebase may-feat-dateTime
// 解決沖突
git rebase  --continue 

參考內(nèi)容

Commit message 和 Change log 編寫指南
Code Review 工具推薦 | Lifecycle