大家好，我是若川。持續組織了近一年的源碼共讀活動，感興趣的可以?點此加我微信ruochuan12?參與，每周大家一起學習200行左右的源碼，共同進步。同時極力推薦訂閱我寫的《學習源碼整體架構系列》?包含20余篇源碼文章。歷史面試系列。另外：目前建有江西|湖南|湖北籍前端群，可加我微信進群。
關于命令行工具，強烈推薦我之前的文章》》》使用 ohmyzsh 打造 windows、ubuntu、mac 系統高效終端命令行工具。用過的都說非常好用。
Git的殺手锏是帶來了輕量級分支，如果你使用svn分支，就會被Git新建分支和切換分支時的速度所震驚。
操作分支在Git中非常高頻，學好分支操作是學好Git的基礎，但在實際工作中，我發現很多同學并不熟悉Git的分支操作，本文試圖通過圖解的方式，講解常用分支操作命令，和命令背后的Git分支模型。
主分支
在Git中新建一個項目后，默認有一個分支，即主分支。主分支一般表示項目的穩定版本，主分支應該包含穩定沒有 Bug 的代碼，并保持隨時可以發布的狀態，對于小型項目來說，只有一個主分支就夠用了，每次我們提交都會創建一個commit節點。
$ git commit -m "c1"$ git commit -m "c2"$ git commit -m "c3"上面的命令會創建三個commit節點，此時master分支如下圖所示：
主分支上應該只包合并提交，所有的迭代應該都在分支上進行，如果是簡單的改動，直接在主分支修改也是可以的，如果功能較復雜，且需要多次提交，不建議在主分支直接修改。
功能分支
當有新的功能要開發時，應該新建一個功能分支，命令如下：
$ git checkout -b feature/a接下來在分支上創建兩個提交，命令如下：
$ git commit -m "c4"$ git commit -m "c5"此時提交樹如下圖所示：
當功能分支開發完成后，需要合并回主分支，合并回主分支有兩種選擇，快速合并和非快速合并，二者的區別在于是否創建提交節點，命令如下：
$ git merge feature/a # 快速合并
$ git merge --no-ff feature/a # 非快速合并快速合并的結果，會直接將 master 指向了 feature/a，如下圖所示：
非快速合并的結果，會在 master 創建合并提交節點，如下圖所示：
兩種合并方式都可以，如果選擇快速合并，需要保證每個提交都是獨立且完整的，如果不滿足要求，Git 支持修改提交歷史，需要修改后再次合并。
修改歷史可以使用 rebase 命令，下面的命令可以修改最近三個提交，將第二個提交的 pick 改為 squash，可以合并第一個和第二個提交，將第三個提交的 pick 改為 edit，可以修改第三個提交的提交信息。
$ git rebase -i HEAD~3pick d24b753 feat: update ci
squash f56ef2f feat: up ci
edit 6c91961 feat: up# Rebase 50ece5c..6c91961 onto 50ece5c (3 commands)
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit在創建當前分支之后，主分支可能又有新的提交，如下圖所示：
在合并之前，建議先將主分支新的提交合并到當前分支，有兩種策略可以選擇，合并和變基，合并操作更簡單，變基操作提交樹更清晰，建議使用變基的方式。
先來看下合并操作的過程，命令如下：
$ git merge master
$ git checkout master
$ git merge feature/a合并操作后的提交樹如下圖所示：
變基會修改feature/a的歷史，就像 feature/a 是在 master 之后開發的一樣，變基命令如下：
$ git rebase master
$ git checkout master
$ git merge feature/a變基操作后的提交樹如下圖所示，虛線的提交是feature/a變基之前的狀態，在變基后，虛線的提交不再有分支指向，但并不會刪除，而是變成Git中的游離節點，在Git執行GC（垃圾清理）操作后，節點才會徹底刪除。
故障分支
如果發現存在 Bug，要盡快修復，此時可以基于主分支新建故障分支，命令如下：
$ git checkout -b bugfix/b當驗證沒問題后，故障分支需要合并回主分支，并在主分支上發布新的補丁版本，命令如下：
$ git checkout master
$ git merge --no-ff bugfix/b# 測試 構建 打標簽 發布到npm主分支更新后，下游的公共分支要及時同步變更，建議使用變基進行同步，命令如下：
$ git checkout feature/a
$ git rebase master故障分支模型如下圖所示，bugfix/b 分支合并到 master 后，feature/a 分支進行了變基操作。
標簽與歷史
每次發布新版本時都要打標簽，版本號需要符合第四章介紹的語義化版本規范，一般功能分支發布次版本號，故障分支發布修訂版本號，使用Git添加tag的命令如下所示：
# 假設當前版本是 1.1.0
$ git tag 1.1.1 # 修改次版本號
$ git tag 1.2.0 # 修改主版本Git 的版本號，還可以添加 v 前綴，兩種風格都可以，建議在一個項目里面保持統一，添加v前綴的版本示例如下：
# 假設當前版本是 v1.1.0
$ git tag v1.1.1 *# 修改次版本號
$ git tag v1.2.0 *# 修改主版本號添加標簽后，提交樹示例如下圖所示。
現在假設最新版本是 v1.2.0 了，突然用戶反饋了 v1.0.0 版本存在 bug，如果是比較小的問題，一般我們會建議用戶升級到最新版本 ，但如果用戶不能升級怎么辦，比如 1.x 到 2.x 存在大版本變化。
出于各種原因，存在需要維護歷史版本的需求，對于還有用戶使用需求的歷史版本，需要提供 bug 修復的支持。
此時創建的標簽就起作用了，可以基于標簽新建一個版本分支，并在版本分支上修復 bug，且發布新的版本，歷史版本分支，不需要再次合并回主干分支，創建標簽分支的示例如下：
$ git checkout -b v1.0.x v1.0.0此時歷史分支的示例如下圖所示。
總結
本文介紹了Git常見的分支命令和分支模型，希望能夠幫助大家更好的掌握Git原理，如果你覺得本文對你有幫助，那就點贊加關注作者吧，如果對本文有任何疑問，歡迎在評論區交流。
·················?若川簡介?·················
你好，我是若川，畢業于江西高校。現在是一名前端開發“工程師”。寫有《學習源碼整體架構系列》20余篇，在知乎、掘金收獲超百萬閱讀。
從2014年起，每年都會寫一篇年度總結，已經堅持寫了8年，點擊查看年度總結。
同時，最近組織了源碼共讀活動，幫助4000+前端人學會看源碼。公眾號愿景：幫助5年內前端人走向前列。
掃碼加我微信 ruochuan12、拉你進源碼共讀群
今日話題
目前建有江西|湖南|湖北?籍 前端群，想進群的可以加我微信 ruochuan12?進群。分享、收藏、點贊、在看我的文章就是對我最大的支持
