Git分支
- 分支
- 分支的本質
- 分支創建、刪除、合併
- 分支的合併與衝突
- git stash
- 分支管理策略
- 主分支
- 輔助分支
分支
在 Git 中，分支（Branch）是一種輕量級的指針，它的核心作用是幫助開發者在不干擾主線代碼的前提下，獨立記錄和管理代碼的修改歷史。
為什麼得分支？
想象一個場景：正在研發一個項目，主線的代碼已經能穩定運行，此時應該製作一個新功能或需要修復一個緊急 bug。如果直接在主線修改，可能會導致主線代碼暫時不穩定，甚至影響其他開發者的工作，而分支的出現處理了這個難題，可以從主線分出一個新分支，在這個分支上專注開發，直到能力完成且測試通過後，再將修改合併回主線。這樣既保證了主線的穩定性，又實現了並行開發。
分支的本質
Git 分支的本質是一個指向特定提交（commit）的輕量級指針。
Git 初始化倉庫時（git init）會默認創建一個主分支，該分支通常命名為 master。這個默認分支與其他分支在本質上沒有區別，它們都是指向提交的指針，唯一的特殊性僅在於默認創建這一初始化行為。默認分支最初指向倉庫的第一個提交（初始提交），當在該分支上進行提交時，分支指針會自動隨新提交向前移動，最終指向該分支的最新提交（即提交鏈的末端）。
此外，Git 中存在一個特殊的 HEAD 指針，它始終指向當前正在工作的分支。例如，當你在 master 分支上時，HEAD 指向 master 分支，而 master 分支指向其最新提交，形成 “HEAD -> 分支 -> 提交” 的指向關係；若切換到其他分支，HEAD 會轉而指向該分支，後續在該分支上的新提交會讓分支指針自動前移，始終指向最新的提交。
第二張圖上我們可以看到創建了dev的分支，當我們切換到dev分支的時候HEAD就會指向dev
進入.git文件夾查看HEAD的內容，所處分支不同，內部的資料指向就不同
若是dev發生修改提交，dev的版本就會向後移動
在master分支上如果進行合併分支就會出現如下圖
分支創建、刪除、合併
通過 git branch 來查看和創建分支，創建標籤記在HEAD指針所指向的提交點創建分支
git branch dev
分支切換到dev分支 git checkout dev
創建分支與切換分支同時完成 git checkout -b dev2
切換到最近一次上一次的分支 git checkout -
在dev2分支創建一個材料A.txt，文件進入工作區，在其他分支上均可看到A.txt文件，且該材料狀態均為工作區狀態。在dev2分支將記錄A.txt添加到暫存區後，在其他分支上也均可看到A.txt文件，且該文件狀態均為暫存區狀態。
在dev2分支提交A.txt文件至版本庫，僅在dev2分支可以看到此記錄，當切換到其他分支時則均無法看到此文件。
可以刪除一個合併後的或者沒有發生變化的分支 git branch -d dev
不能刪除自己所在的分支
如果一個分支發生了變化，沒有合併不能刪除，如果要強制刪除可以使用 git branch -D dev2
分支的合併與衝突
切換到master上做dev2 的合併，git merge dev2
發現master分支上也添加了A.txt這個文件
如果修改的是同一個文件也可以做分支合併，通過合併發現master分支上也合併了dev2修改的內容，合併之後dev2的刪除就被允許了
此時我們在 dev2 分支裏修改 A.txt 資料添加一行 dev2 00001 後提交，在 master 分支裏面修改 A.txt 資料同時添加一行 master 00002 後提交
合併的時候發現出現分支衝突
<<<<<<< HEAD 當前指向的分支所修改的內容
======= 分隔線，上下分別是兩個分支的衝突內容
>>>>>>> dev2 dev2分支所修改的內容
需要手工合併，根據實際需求，決定保留哪部分內容或整合兩者
修改完後，在dev2分支下的A.txt文件內容也跟着更新了
可以通過圖形來查看衝突的提交日誌 git log --graph
git stash
git stash 是 Git 中用於臨時保存工作區和暫存區修改的命令。在當前分支做了一些未完成的修改（不想立即提交），但需要臨時切換到其他分支時，可通過 git stash 將這些修改暫存起來，讓工作區恢復到乾淨狀態（與最近一次提交一致），方便進行其他操作。
最新的暫存就是在dev分支修改 A.txt、新增 b.txt，git stash 將內容保存至堆棧中，再新增 c.txt，將其添加至暫存區，再將內容保存至堆棧中，棧頂
git stash list 列出堆棧區保存的所有未完畢的任務
git stash pop 出棧，恢復並刪除暫存
可以在任意分支上取出並繼續完成任務，需要注意的是出棧一個任務並提交後才能夠出棧另一個任務
在 master 分支上出棧
分支管理策略
從上圖可以看到關鍵包含下面幾個分支：
- master：git默認主分支（這裏不作運行）
- stable：穩定分支，替代master，主要用來版本發佈
- develop：日常開發分支，該分支正常保存了開發的最新代碼
- feature：具體的功能開發分支，只與 develop 分支交互
- release：release 分支可能認為是 stable分支的未測試版
- bugfix：線上 bug 修復分支
在 Git 分支管理中，主分支（Main Branches） 和輔助分支（Supporting Branches） 是兩類效果互補的分支，共同支撐項目的研發、測試、發佈和維護流程。
主分支
因為master分支大家不作管理，存放可部署到生產環境的穩定代碼，針對stable和develop這兩個主分支來講解。
stable分支：用來發布，管理着多個穩定的版本
develop分支：開發階段的主分支，整合所有已完成的效果研發，是測試環境的代碼源
啓用這兩個分支就具有了最方便的開發模式：develop 分支用來開發功能，開發完成並且測試沒有問題後，則將 develop 分支的代碼合併到 stable分支併發布。
輔助分支
從主分支（或其他輔助分支）派生的臨時分支，用於隔離特定任務（如開發新功能、修復 bug、準備發佈等），任務做完後需合併回目標分支並刪除，避免長期存在導致代碼混亂。就是輔助分支
Feature分支
feature 分支用來開發具體的功能，一般基於develop分支，最後做完功能後再合併到develop分支。
比如，目前我們針對develop分支來做功能編寫，在開發的過程中會有緊急需求需要構建，且在本次版本發佈時間之前要能測試完成。我們允許基於之前穩定版本另開一個feature分支來做緊急需求的開發，發佈並進行測試，完成之後再合併到develop分支上。
release分支
release分支作為預發佈分支，release 分支從 develop 分支 fork 出來，最終會合併到 develop 分支和 stable 分支，合併到 stable分支上就是可以發佈的代碼了。
為什麼我從develop分支fork出來，還要合併到develop分支中呢？因為大家在release分支上難免會有bug產生，修復bug也是在release分支上，所以必須要合併到develop分支。
bugfix分支
bugfix 分支用來修復線上bug。當線上代碼出現 bug 時，我們基於 stable 分支開一個bugfix分支，修復 bug之後再將 bugfix分支合併到stable分支並進行發佈，同時develop 分支作為最新最全的代碼分支，bugfix分支也需要合併到 develop 分支上去。
