git入門五（分支合併衝突和衍合）

分支合併衝突的處理

 

合併分支的衝突時在不一樣的分支中修改了同一個文件的同一部分，程序沒法把兩份有差別的文件合併，這時候須要人爲的干預解決衝突。當前處於master 分支，當dev 分支和master 分支對至關部分test1.txt 都作了修改，當合並dev 分支的時候，合併會出現分支衝突以下：查詢當前工做區的狀態能夠顯示那些文件發生合併衝突，任何包含未解決衝突的文件都會以未合併（ummerged)的狀態列出，git 會加入標準衝突解決標記，能夠經過手工定位來解決這些衝突。能夠看大 =======隔開以上部分就是當前活動分支，也是合併的基準分支（head 指向的master分支），======分隔符如下的是dev分支中的內容。解決衝突的辦法無非是兩者選其一或者由你親自整合到一塊兒。好比你能夠兩部份內容合併成 一部份內容。

 

$ git branch

  dev

* master

  testing

 

$ git merge dev

Auto-merging test1.txt

CONFLICT (content): Merge conflict in test1.txt

Automatic merge failed; fix conflicts and then commit the result.

 

$ git status

# On branch master

# Unmerged paths:

#   (use "git add/rm <file>..." as appropriate to mark resolution)

#

#       both modified:      test1.txt

#

no changes added to commit (use "git add" and/or "git commit -a")

 

$ notepad test1.txt

<<<<<<< HEAD

now this is bug fix branch

=======

this is branch merge conflict problem

>>>>>>> dev

 

同時還能夠用圖形化界面的工具來處理分支，git mergetool 命令會調用時當前系統配置的合併工具。合併完成後能夠查詢狀態git status 來確認全部衝突都已經解決。若是衝突解決都已完成，能夠把合併後的內容提交到暫存區，能夠用git commit 完成此次合併提交。針對衝突合併，須要寫好註釋說明，後續查看會更加簡單方便。

 

$ git commit -m "master merge dev branch"

[master 05a2f29] master merge dev branch

 1 files changed, 4 insertions(+), 1 deletions(-)

 

分支的管理

 

git branch 是查詢當前全部分支的清單，*號的表示當前的活動分支，也就是當前所在的分支。也就是說若是如今有提交更新，當前的工做分支master 分支或向前移動。若要看各個分支最後一個提交對象的新，能夠經過git branch -v 來查看。

 

$ git branch

  dev

* master

  testing

 

$ git branch -v

  dev     be70ec8 dev

* master  05a2f29 master merge dev branch

  testing 0c8f2de testing branch change

 

在全部分支清單中，能夠篩選出那些與當前分支還沒有合併，經過參數--merge 能夠篩選出那些分支在當前分支的上游，這些分支只須要經過fast-forward 移動指正就能夠移動噹噹前最後提交給對象。--no-merged 能夠查看還位和當前分支合併的分支。如dev分支和當前分支還未合併。若是之前是無效的分支，能夠經過git branch -d 刪除制定的分支。

$ git branch --merged

* master

  testing

  

$ git branch --no-merged

  dev

  

$ git branch -d testing

Deleted branch testing (was 0c8f2de).

 

 

 

長期分支

 

git只是簡單的三方合併分支的特性，因此在腳長的一段時間內，把多個分支合併到一個分支或者同時擁有多發分支進行開發。因爲每一個分支都有特定的任務，隨着開發的推動，隨時能夠把某個特性分支合併到其它分支中。需求使用git 的開發者都喜歡用這種方式開發，通常來講僅僅在master 分支保留穩定的代碼，就是已經發布或者通過測試的代碼。與此同時，你能夠同時擁有多個開發分支。每一個開發分支都有特定的任務。如還有一個叫develop 的平行分支，專門擁有後續的開發，僅擁有穩定性的測試。一旦到達某種穩定的狀態就能夠合併到master 分支。若是有其它特性的短缺分支可以經過測試，而且不會引如更多錯誤後，就能夠併到主幹master分支中。等待下一次發佈。

 

隨着提交對象的不斷右移指針，穩定分支老是在提交歷史中落後一大截，並且前言分支老是比較靠前。穩定分支老是滯後，通過測試比較穩定的對象或者集合才被合併到穩定的分支上。這樣能夠維護不一樣層次的穩定。

 

特性分支

 

在任何規模的項目中可使用特性分支（topic).一個特性是指一個短時間的，用來實現單一特性與其相關的工做分支，你能夠在之前版本中從未作過相似的這樣事情，由於建立和合並分支的消耗太大。然而在git中，一天以內建立，刪除和合並多個分支是常見的事情。在建立特性分支後，你能夠提交合併到主幹分支，而後刪除他，該技術讓你迅速且徹底進行語境切換。由於你的工做分散在不一樣的流水性力，每一個分支力改變都和他的目標特性相關。你能夠把作出的改變保持在特性分支幾分鐘。幾天甚至幾個月。等他們成熟之後再合併。而不用在意他們創建的順序和進度。

 

通常分支都是在本地。大部分都是本地分支。這一點很重要。當前使用合併分支的時候，一切都在你的git 倉庫中進行的，徹底不與服務器交互。只有當你有固定的分支或者分享須要和其它合做夥伴共享的時候，才須要推送到中心服務器。

 

 

遠程分支：

 

remote branch 是對遠程倉庫中的分支的索引。他們是沒法移動本地分支。只有在git進行網絡交互時纔會更新。遠程分支就是書籤，提醒着你上次連接遠程倉庫時上面各個分支的位置。 咱們用倉庫名/分支名 這樣的形式表示遠程分支。好比咱們想一想上次同 origin 倉庫進行通信時master 分支的樣子。就應該查看origin/master 分支。若是你和同伴一塊兒修復某個問題。他們推送一個iss53分支到遠程倉庫。雖然你可能也有一個本地的iss53分支，但指向服務器上最新的更新的英是origin/iss53分支。

 

假如團隊中心服務器git地址：git.ourcompany.com.。若是你從這裏克隆，git會自動在爲你將次遠程倉庫嗎命名爲origin。並下載其中的數據，創建一個指向它的master分支指針。在本地命名爲Origin/master。但你沒法再本地更改數據，接着git創建一個屬於你本身本地的master分支。始於origin上master分支相同的位置。以下圖

 

 

若是你在本地master 分支作了些改動。與此同時本地分支向前推動。只要本地沒有向遠程服務器推送，origin/master 分支指針任然保持在原位不會移動。

 

 

 

 

在本地工做同時有人向遠程倉庫推送內容會讓歷史開始分流。能夠容許git fethch origin 來同步遠程服務器上的數據到本地。該命令首先找到origin 是哪一個服務器。從上面獲取你未擁有的數據。更新你本地的數據庫。而後把Origin/master的指針移動到他最新的位置上。

 

 

若是有多個遠程分支的項目是若是進行工做的。咱們假設你還有另一個內部使用的遠程服務器。經過git remote add 命令吧它加爲當前項目的遠程分支之一。咱們把它命名爲teamtone,以便代替完整的git url。

 

如今把另一個遠程服務器添加爲遠程倉庫了，如今能夠用git fetch teamtone 來獲取小組服務器你尚未的數據，因爲當前服務器的內容是origin服務器上的子集，git不會下載任何數據。而只是簡答建立一個名爲teamone/master 的遠程分支。指向teamone 服務器上master 分支全部在的提交對象 31b3e 以下圖：如今你在本地就有了一個指向teamone 的索引。

 

 

 

推送本地分支

 

要想和其它人分享某個本地的分支，你須要把它推送到一個擁有些權限的遠程倉庫。你建立的本地分支部會由於你的寫入操做而被自動同步到你引入的遠程服務器上，你須要明確的執行推送分支的操做。換句話說，對於無心分享的分支，你儘管保留私人分支好了。而只推送那些協同工做要用到的特性分支。若是有個交severfix 的分支須要和他人一塊兒開發，能夠運行git push (遠程倉庫名） 分支名。

 

$ git push origin serverfix

Total 0 (delta 0), reused 0 (delta 0)

To git@github.com:andy/test.git

 * [new branch]      serverfix -> serverfix

 

git 自動把serverfix 分支名擴展爲refs/heads/serverfix:refs/heads/serverfix,意思是「取出我在本地的serverfix分支，推送到遠程倉庫的serverfix分支中區，通常在同一分支上能夠省略，  git push origin serverfix:serverfix，還能夠把本地分支推送到遠程不一樣的分支。能夠用已經存在的新遠程分支或新的遠程分支。

當你再次從遠程獲取服務器上數據的時候，同伴會獲取到origin/serverfix 和 origin/newfix 的分支，並指向服務器上serverfix 所指向的版本。在fetch操做下載好新的遠程分支以後。你任然沒法再本地編輯遠程倉庫中的分支。換句話說你不會有一個新的serverfix 分支。有的只是一個你沒法移動的Origin/serverfix指針。你若是須要把該遠程分支的內容合併到當前分支，能夠運行git merge origin/serverfix ,若是想要一份本身的serverfix來開發。能夠在遠程分支的基礎上分化一個新的分支來。這會切換到新的serverfix 的本地分支。其內容同遠程分支 origin/serverfix 一致。這樣能夠繼續開發了。

 

$ git push origin serverfix:newfix

Total 0 (delta 0), reused 0 (delta 0)

To git@github.com:andy i/test.git

 * [new branch]      serverfix -> newfix

 

$ git fetch origin

remote: Counting objects: 19, done.

remote: Compressing objects: 100% (7/7), done.

remote: Total 17 (delta 6), reused 16 (delta 5)

Unpacking objects: 100% (17/17), done.

From github.com:andy i/test

 * [new branch]      dev        -> origin/dev

   894ed8b..37b40ce  master     -> origin/master

 

跟蹤遠程分支

 

 從遠程分支checkout 出來的本地分支。稱爲跟蹤（tracking branch）,跟蹤分支是一種和某個遠程分支有直接聯繫的本地分支。在跟蹤分支裏輸入git push,git 會自行推斷應該向那個服務器的那個分支推送數據。一樣，在這些分支裏運行git pull 會回去遠程索引，並把它們的數據合併到本地分支中。

 在克隆倉庫時，git 一般會自建立一個名master 的分支來跟蹤，這正是git push 和 git pull 一開始就能正常工做的緣由。固然，你能夠爲所欲爲設定其爲跟蹤分支，好比在origin 上除了master 以外的其它分支。剛纔咱們已經開到了這樣的一個例子。 git checkout -b 分支名  遠程名/分支名， 還能夠用 --track  選項。 若是本地分支和遠程分支的名稱不同，能夠本地分支換個名稱。

 

$ git checkout -b serv origin/serverfix

Branch serv set up to track remote branch serverfix from origin.

Switched to a new branch 'serv'

 

$ git branch

  master

* serv

  serverfix

 

刪除遠程分支

 

若是再也不須要摸個遠程分支了，好比搞定某個特性併合並進了遠程的master 分支（或任何其餘存放穩定的代碼分支），能夠用這個命令 git push 遠程名：分支名。若是運行這個命令，服務器上的分支就沒了，git puhs 遠程名 本地分支：遠程分支 語法，若是省略本地分支。那就是等提早空白而後把它變成遠程分支。

 

分支的衍和

 

把一個分支中的修改整合到另外一個分支的辦法由兩種：merge 和 rebase(翻譯爲衍合）。

 

基本的衍合操做，當開發進程分叉到兩個不一樣的分支，有各自提交了更新。最簡單的整合方式是合併merege 命令。他會把二者共同的祖先ac631f6進行三方合併。併合後產生一個結果就是兩條分的合併點。

 

其實除了合併之外，還有另一個選擇，能夠把7599941產生變化的補丁在4632de基礎上從新打一遍。在git 裏着叫衍合（rebase),有了rebase命令，就能夠在把在一個分只裏提交的改變移動到另外一個分支重方一遍。他們的原理是回到兩個分支最近共同的祖先。根據當前分支（也就是要進行衍合的分支）後續歷次提交的對象在這裏分支只有一個提交。生產一系列文件補丁，而後基地分支（也就是主幹分支master 的最後一個提交對象爲新的出發點，逐個應用以前準備好的補丁文件，最後會生產一個新的合併提交對象。從而改寫須要衍合分支的提交歷史。使他成爲master 分支的直接下游。