前言
一個專案的分支，一般包括主幹 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