「單點登陸與權限管理」系列第二部分,Demo項目的設計和開發,須要一段時間才能完成。這段時間,會把之前學習、實踐、梳理過的知識分享給你們,但願你們可以喜歡。html
「單點登陸與權限管理」系列第一部分索引:git
- session和cookie介紹
- HTTP重定向
- 單點登陸介紹
- cookie安全問題
- 權限管理介紹
接下來,會分享「git分支管理和工做流規範」相關內容,當一個項目大了後,會有多人共同協做開發,若是沒有相關規範,代碼合併的時候會有不少衝突,代碼的版本和提交歷史也會顯得很亂。針對這2個問題,能夠經過分支的管理、工做流規範很好的解決。github
針對不一樣的場景建立不一樣的分支,始終保持主分支可靠、乾淨,好比新增功能、修復線上問題、修復測試環境的bug等場景,須要建立不一樣的分支。另外,要對下一版本要上線的功能提早規劃好,把功能細分,分配給每一個人去完成,功能相互依賴的在同一個分支,不肯定要上線的功能要單首創建分支,這樣能夠減小合併時的衝突。數據庫
提交代碼時,要保持提交歷史的清晰,提交的註釋也要規範,關於提交歷史,總結了3個要點:安全
- 一個git用戶很是重要的技能是可以維護一個清晰的語義化的變動歷史;
- 經過查看版本變動歷史就能夠反映出團隊的開發目的、功能變動;
- 版本變動歷史記錄的是代碼的發展,而不是開發者在編碼時的活動;
會分3篇文章分享「git分支管理和工做流規範」:cookie
本篇主要介紹下git相關概念,太基礎的我就不介紹了,網上資料比較多,主要包括:session
- 文件的狀態
- 分支的概念
- 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對象的可變指針。post
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工具
最後附上經常使用的命令速查表: