「單點登入與許可權管理」系列第二部分，Demo專案的設計和開發，需要一段時間才能完成。這段時間，會把以前學習、實踐、梳理過的知識分享給大家，希望大家能夠喜歡。
「單點登入與許可權管理」系列第一部分索引：
接下來，會分享「git分支管理和工作流規範」相關內容，當一個專案大了後，會有多人共同協作開發，如果沒有相關規範，程式碼合併的時候會有很多衝突，程式碼的版本和提交歷史也會顯得很亂。針對這2個問題，可以通過分支的管理、工作流規範很好的解決。
針對不同的場景建立不同的分支，始終保持主分支可靠、乾淨，比如新增功能、修復線上問題、修復測試環境的bug等場景，需要建立不同的分支。另外，要對下一版本要上線的功能提前規劃好，把功能細分，分配給每個人去完成，功能相互依賴的在同一個分支，不確定要上線的功能要單獨建立分支，這樣可以減少合併時的衝突。
提交程式碼時，要保持提交歷史的清晰，提交的註釋也要規範，關於提交歷史，總結了3個要點：
- 一個git使用者非常重要的技能是能夠維護一個清晰的語義化的變更歷史;
- 通過檢視版本變更歷史就可以反映出團隊的開發目的、功能變更；
- 版本變更歷史記錄的是程式碼的發展，而不是開發者在編碼時的活動；
會分3篇文章分享「git分支管理和工作流規範」：
- git相關概念
- 具體規範
- 不同場景細化和演示
本篇主要介紹下git相關概念，太基礎的我就不介紹了，網上資料比較多，主要包括：
- 檔案的狀態
- 分支的概念
- merge合併
- rebase衍合
- git工作流程
檔案的狀態
狀態型別
- 已修改：修改了某個檔案，但還沒有提交儲存;(沒有add)
- 已暫存：已修改的檔案放在下次提交時要儲存的清單中;（已add，沒有commit）
- 已提交：檔案已經被安全地儲存在本地資料庫中;（已commit）
工作目錄、暫存目錄、git目錄
3個目錄與檔案的狀態是對應的，不同的狀態放在不同的目錄。
git物件
- 物件包括提交、檔案樹、檔案內容、其他操作物件;
- 用40位十六進位制數字組成;
- 可通過git cat-file 命令檢視物件資訊;
基本工作流程
- 在工作目錄中修改某些檔案;
- 對修改後的檔案進行快照，然後儲存到暫存區;
- 提交更新，將儲存在暫存區域的檔案快照永久轉儲到git目錄中;
狀態相關命令
- git status 顯示哪些檔案已修改、哪些檔案已暫存、未提交;
- git diff 比較不同狀態的檔案
- 預設比較工作目錄、暫存區檔案快照的差異;（修改後，未暫存的檔案）
- --cached 比較已暫存、上次提交時的快照之間的差異;
- git reset 進行撤銷操作，將當前分支重設到指定的commit
- --hard 重設工作目錄和暫存區；
- --mixed 預設方式，僅重設暫存區，工作目錄不變；
- –soft 僅僅把HEAD指向，commit之後的commit會進入暫存區；
分支的概念
本質上，分支僅僅是指向commit物件的可變指標。
git如何知道你當前在哪個分支上工作？
- 儲存著一個名為HEAD的特保指標；
- HEAD是一個指向你正在工作中的本地分支的指標；
通過git branch -a 檢視分支時，會看到所有分支，包括本地分支、遠端分支；
分支的合併主要有2種方式，merge和rebase。merge主要是自動合併，針對不同場景有不同的合併策略，rebase主要是手動合併，可針對每次commit指定不同的合併策略，下面會分別介紹。
merge合併
- --commit --no-commit 合併後，是否自動產生一個合併結果的commit節點;
- --edit --no-edit 是否接受自動合併的資訊;
- --ff --no-ff選項
- 預設情況下，git執行“快進式合併”(fast-farward merge)，不會創造一個新的commit節點;
- --no-ff，會建立一個新的commit;
- --log --no-log
- 合併提交時，除了分支名以外，是否還包括commit節點的日誌資訊
- --squash
- 不保留待合併分支上的歷史資訊，也不提交、不移動HEAD，需要一個額外的commit命令;
- 判斷是否使用--squash選項的最根本的標準是，待合併分支上的歷史是否有意義;
- -- abort
- 拋棄當前合併衝突的處理過程並嘗試重建合併前的狀態;
rebase衍合
$ git rebase -i [branch|]
三個操作命令：--continue、--absort 和 --skip，這三個命令的意思分別是“繼續”、“退出”和“跳過”
一定要注意的地方：
- 一旦分支中的提交物件釋出到公共倉庫，就千萬不要對該分支進行衍合操作;
- 在進行衍合的時候，實際上拋棄了一些現存的提交物件而創造了一些類似但不同的新的提交物件;
- 如果你把原來分支中的提交物件釋出出去，並且其他人更新下載後在其基礎上開展工作，而稍後你又用git rebase 拋棄這些提交物件，把新的重演後的提交物件釋出出去的話，你的合作者就不得不重新合併他們的工作，這樣當你再次從他們那裡獲取內容時，提交歷史就會變得一團糟;
- 把衍合當成一種在推送之前清理提交歷史的手段，而且僅僅衍合那些尚未公開的提交物件；
具體的示例，網上資料很多，就不在此說明了。
git工作流
協作必須有一個規範的工作流程，讓大家有效地合作，使得專案井井有條地發展下去。
網上對這一部分的介紹也很多，介紹比較多的就是git flow規範，可以參考下面2篇文章： [1] 阮一峰：git工作流程 [2] git-flow工具
最後附上常用的命令速查表：