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 分支的直接下游。