前端項目git操作命名規範和協作開發流程
前言
一個項目的分支，一般包括主幹 master 和 開發分支 dev，以及若幹臨時分支
分支命名規範
分支: 命名: 說明:
主分支 master 主分支，所有提供給使用者使用的正式版本，都在這個主分支上釋出
開發分支 dev 開發分支，永遠是功能最新最全的分支
功能分支 feature-* 新功能分支，某個功能點正在開發階段
釋出版本 release-* 釋出定期要上線的功能
修複分支 bug-* 修複線上代碼的 bug
驗證分支 demo-* 技術調研，完成後删除該分支 關聯和操作遠端分支
- 假設有一個遠端分支為 dev，在本地建一個同名分支，然後執行下邊的 pull 操作（第一次執行pull操作），就可以完成本地和遠端分支的關聯。
- 以後就可以進行日常的 pull 和 push 操作，注意需要多一個 origin 關鍵字
建立本地同名分支 git branch dev
拉取遠端分支 git pull origin dev
推送遠端分支 git push origin dev git操作流程
//暫存
git add .
//送出
git commit -m fix-xxxxx（舉例）
//拉取最新
git pull
//處理沖突，重新傳回開頭，操作，直到沒有沖突
//處理沖突完成，推送代碼
git push commit 命名規範
- feat: 一個新功能
- fix: 一個 bug 修複
- docs: 僅僅修改了文檔，比如 README, CHANGELOG, CONTRIBUTE 等
- style: 不影響代碼邏輯的修改，比如空格、格式縮進、删除分号等
- refactor: 代碼重構
- perf: 提升性能的改動
- test: 增加或修改測試
- chore: 改變建構流程、或者增加輔助工具、依賴庫等
多人協作模式
add commit pull push 的順序
- 一般來說，本地開發時要随時進行 add 操作，執行 add .
- 一般來說，每天需要将最新的開發分支 dev，進行一次遠端送出（可能有merge）
- 對于 commit 和 pull 操作的先後順序，有兩個方案，如下：
- 方案一，在本地修改與遠端代碼無沖突的情況下，優先使用：pull->commit->push 的流程
- 方案二，在本地修改與遠端代碼有沖突的情況下，優先使用：commit->pull->push 的流程
- 盡量使用方案一，因為方案二會增加不必要的 merge 記錄
- 最後進行 push
pull 後的沖突處理
- 如果 pull 或 push 失敗報錯，則因為遠端分支比你的本地更新，需要先用 git pull 試圖合并
- 如果合并有沖突，則解決沖突，并在本地重新 commit；
- 沒有沖突或者解決掉沖突後，再用 push 推送遠端分支
沖突處理
- 當執行 pull、push、merge等操作時，如果發生沖突，==git會在指令行提示并列出所有的沖突檔案==
- 這時，需要在項目中檢視每一個沖突檔案，==git會對檔案中各處的沖突進行标記==，标記一般為這樣：
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> dev - 其中，<<<<<<< HEAD 和 ======= 之間的内容，為遠端分支版本
- ======= 和 >>>>>>> dev之間的内容，為本地開發分支版本
- 你要做的就是選擇使用其中的一個版本，同時将另一個版本的代碼删除掉
- 處理該檔案所有的标記沖突
- 處理git指令提示的所有沖突檔案中的沖突
- 處理完成後，重新進行 pull 或 commit 操作
- 如果沒有再報錯，就可以執行push
posted on 2019-02-19 13:27 悔不當初-s 閱讀(...) 評論(...) 編輯 收藏