Git的分支命令详解
為什么80%的碼農都做不了架構師？>>> ??
我們已經了解了git非常重要的三個組件:blob、commit、tree，這三個組件都是以二進制的方式存儲的，
而且都是用hash碼作為主鍵的唯一名稱。
接下來我們將詳細的介紹git的分支。
分支在項目的開發過程中是非常重要的，分支旨在解決版本管理之中的沖突問題。分支的使用一定要在整個項目團隊中達成一致，否則分支太多，最后合并的時候會存在一大堆的問題，目前已經有了一套成熟的分支管理體系git-flow，這套體系我們會在以后詳細介紹，這一次我們主要介紹git和分支相關的各種命令。
1、首先建立自己的git目錄。進行如下操作：
D:\test\git>git init Initialized empty Git repository in D:/test/git/.git/ ***完成工廠的創建D:\test\git>echo a > a.txtD:\test\git>git add .D:\test\git>git commit -m "add a.txt" [master (root-commit) df11b43] add a.txt1 file changed, 1 insertion(+)create mode 100644 a.txt ***完成第一版本的提交D:\test\git>echo a1 > a1.txtD:\test\git>git add .D:\test\git>git commit -m "add a1.txt" [master e5fb3fb] add a1.txt1 file changed, 1 insertion(+)create mode 100644 a1.txt ***完成第二個版本的提交D:\test\git>git log commit e5fb3fba474eaa5e429bd51945caeae29b46e7b9 Author: pm <pm@gmail.com> Date: Sat Dec 31 22:08:23 2016 +0800add a1.txtcommit df11b43c129bd3761b0855ef146d0a8a9f9183a6 Author: pm <pm@gmail.com> Date: Sat Dec 31 22:02:43 2016 +0800add a.txt***通過git log發現已經存在兩個版本了。通過以上操作基本完成了項目的初始化操作，這里我們建立了兩個版本。
2、接下來我們使用下一個命令來創建一個分支。
git branch b1這樣就創建好了一個分支b1,可以通過：
git branch查詢所有的分支：
我們發現有兩個分支，一個是master，另外一個是剛才創建的b1，master是綠色的并且前面有個*，表示
我們目前處于master分支。
現在的狀態：
????有兩個分支，有兩個文件a.txt和a1.txt。
3、下一步我們需要轉換到b1這個分支中，使用下面的命令：
git checkout b1此時就可以轉換到b1的分支中，同樣我們也可以通過如下命令完成分支的創建和轉換：
git checkout -b b2這將會創建一個分支b2，并且切換到分支b2中
4、我們就在b2分支中進行一些修改，并且完成一次版本的提交。
此時在b2分支中就有了三次提交，而且有了三個文件。
我們再切換回分支master看看情況：
我們發現master分支看不到b2分支的任何信息，而且文件也沒有在b2分支中添加的b2.txt。
我們繼續在master分支中添加一個文件m.txt。然后完成版本的提交：
此時在master中有3個文件:a.txt,a1.txt,m.txt,其中m.txt是在分支創建之后才創建，而且目前master分支
也有三個commit，切換回b2分支，查詢文件：
????我們發現在b2上并不存在master在創建分支之后的信息，此時master分支的修改不會在b1或者b2中
????有所呈現。
我們繼續如下操作，選擇b2分支，然后再次創建一個分支b2_1：
此時需要注意的是我們是在b2分支上創建的分支b2_1，所以b2_1分支僅僅只能看到b2分支上的東西，
這里就得出了一個結論，在某個分支上創建的分支是以該分支為基礎的。此時在b2_1中添加文件并且完成
提交。并且切換到b1中進行一次版本的提交,再在b2中進行一次版本提交，執行的命令如下：
查看當前每個分支的情況，可以使用如下命令讓git log 在一行顯示：
git log --pretty=oneline有沒有發現，現在分支已經開始混亂了，我們簡單分析下分支目前的狀態：
我們最早的master分支有兩次提交，之后創建了b1和b2分支，并且分別完成了一次提交，然后在master上也完成了一次提交，在b2分支上又創建了新的分支b2_1，然后完成了一次提交。大家有沒有發現不管怎么分析，當分支變多之后也很難進行管理，這也就是為什么我們要確定分支管理思路的原因，很幸運，git-flow為我們定義了一套合理的分支管理流程，我們將會在后面來進行介紹。
現在我們已經了解了分支的創建操作，之后我們需要對分支進行合并，剛才我們的操作是人為避開了沖突，我們先了解分支合并步驟，之后再來看產生沖突之后的情況。分支的合并非常的簡單，只要在需要合并的分支上使用git merge 要合并的分支就完成了。
5、下面的操作完成了在master分支上合并b1：
git checkout master git merge b1合并非常的順利，但是注意，合并完成之后，會產生一個新的commit組件，通過cat-file查詢這個組件，
我們會發現該組件有兩個parent，看看這兩parent的id，就是原來的master的最新版本id和b1的最新
版本的id。我們發現一個版本是可能存在多個parent的，只要分支進行合并之后，parent指向了它的
上一個版本。
接著我們來合并b2分支，b2分支有些特殊，因為b2分支上還存在b2_1分支。
git merge b2我們發現合并非常的順利，git并不會將b2_1的內容合并進來，我們可以繼續執行git merge b2_1完成合并，也同樣順利完成，git log --pretty=oneline查詢，我們發現每次合并都產生了新的commit組件：
我們發現git的分支合并非常的靈活高效，在合并完分支之后我們就需要刪除多余的分支，
使用-d參數完成刪除：
使用以上命令就完成了對b1分支的刪除，之后我們來刪除b2分支，我們發現b2分支的刪除也非常的順利，而且刪除完成之后b2_1分支依然存在。我們發現雖然b2_1是在b2的基礎上創建的，但兩者之間的關聯其實并不密切（后面我們會了解到分支的名稱僅僅只是那個hashid的標示，刪除了分支，其實版本依然是存在的）。而且，我們發現b2_1上的parent依然是我們刪除了b2分支的版本。
但是此時執行git branch -d b2_1，我們發現報了一個錯誤。他告訴我們b2_1并沒有被完全合并，由于它是在b2上衍生出來的分支，應該要先合并到b2中，但是此時b2已經被刪除了，我們可以使用
git branch -D b2_1強行刪除分支。所以雖然git對分支的合并的管理非常靈活，但是在實際使用中，如果在某個分支上創建了子分支，依然應該先完成子分支的合并再將其合并到master中。
6、下面我們演示一個帶沖突的分支合并，當兩個分支同時修改某個文件的相同行時就會發生這個沖突。
我們會執行如下一組命令：
此時兩個版本中co.txt的內容不一樣，而且是在同一行，我們進行一下合并：
git checkout master git merge bc我們發現產生沖突了，在co.txt中顯示了沖突的位置，當發生這個沖突，我們只能在團隊的內部進行協調
解決這個沖突，這是分支合并時修改了相同文件，帶來的必然結果，只能人工解決或者通過SourceTree之類的工具選擇使用那個版本。所以分支雖然給我們帶來了很多便利，但是一定要合理的規劃好分支的使用策略才能讓分支發揮出最大的功效，接下來將介紹基于git-flow的分支管理策略。
轉載于:https://my.oschina.net/pmos/blog/821034
總結
以上是生活随笔為你收集整理的Git的分支命令详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 电动汽车与ADAS
- 下一篇： JDK1.7安装配置环境变量+图文说明J