pro_git第三章 git分支

概述：本章介绍核心，git的分支操作，其中难点有git 分支的合并，冲突解决，和git rebase

1.何谓分支

       要明白什么是分支，首先要明白git的仓库是如何组织的。在第一章中，我们知道，git是进行快照存储的，那么当git仓库管理着三个文件的时候，实际上仓库中有5个存储对象。

        其中三个blob表示文件，tree表示目录树组织，还有一个包涵提交信息，指向tree对象的commit对象。多次提交以后的对象，存储状况如下：

        其中parent指向前一个提交，另外有一个域指向提交快照。

        理 解了上述的存储模型，我们要说，git的分支实际上就是指向commit对象的指针，每次提交，该指针都会向前移动，如图：

        创建一个test分支，实际上就是创建了一个指针，存储对对象的实际内容变化如下：

        为了区别git在哪个分支上工作，我们设计了HEAD指针，用于指向当前分支的最近对象。提交一次，另外转移到其他分支的情况如下；

2.基本的分支和合并

2.1基本分支

        创建基本分支：$git branch testone

        or $git checkout -b testtwo

        一段时间以后，git分支的新建情况如图：

        这个时候产生需求一：把hotfix分支并入master分支

        解决方法：

       $giit checkout master

         $git merge hotfix

过程说明：

    Updating f42c576..3a0874c
    Fast forward
    README1 -
    1 files changed, 0 insertions(+), 1 deletions(-)

    请注意,合并时出现了 “Fast forward”(快进)提示。由于当前 master 分支所在的commit 是要并入的 hotfix 分支的直接上游,Git 只需把指针直接右移。换句话说,如果顺着一个分支走下去可以到达另一个分支,那么 Git 在合并两者时,只会简单地把指针前移,因为没有什么分歧需要解决,所以这个过程叫做快进(Fast forward)。

    合并以后的分支情况如图：

    现在，可以删除hotfix分支了：$git branch -d hotfix

    此时，iss53分支中的内容还没有刚才修改的内容。可以使用merge将修改并入其中

2.2基本合并

    现在，要想把iss53和hotfix进行merge，需要出同源合并点，然后自动创建一个commit。

    命令： git checkout master

    git merge iss53

结果：

2.3冲突的合并

    如果你要合并的两个分支，修改了同一个文件的内容，此时就会产生冲突，理论上，这种冲突只能由人来解决。

    所以解决的方法是先：

    git merge；

    运行git status查看情况

     手动修改bothmodified对应的文件

    使用git commit进行提交

3.分支管理

    需求：查看每个分支最后一次commit的信息

命令：git branch -v

需求二：查看哪些分支被合并哪些分支没有被并入当前分支

    git --merge 

    && git --no-merged  

4.分支式工作流程

略

5.远程分支

        注意：我们能够改动的是本地数据的master分支，不能改动的是远程的orgin/master分支。original/master分支只会在于远程服务器通信的时候才会改动。可以运行 git fetch origin 来进行同步（远程分支和本地的origin/master分支）。该命令首先找到 origin 是哪个服务器(本例为 git.ourcompany.com),从上面获取你尚未拥有的数据,更新你本地的数据库,然后把origin/master 的指针移到它最新的位置。

5.1推送

    如果你有个叫 serverfix 的分支需要和他人一起开发,可以运行 git push (远程仓库名) (分支名)；

$ git push origin serverfix
Counting objects: 20, done.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 1.74 KiB, done.
Total 15 (delta 5), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new branch]
serverfix -> serverfix

    注意，在推送以前，如果想推送到自己的github账户，需要先新建自己github账户上相关的仓库和分支。

    这 其 实 有 点 像 条 捷 径。Git 自 动 把 serverfix 分 支 名 扩 展 为 refs/ heads/ server-fix:refs/heads/serverfix,意为“取出我的 serverfix 本地分支,推送它来更新远程仓库的serverfix 分支”。我们将在第九章进一步介绍 refs/heads/ 部分的细节,不过一般使用的时候都可以省略它。也可以运行 git push origin serverfix:serferfix 来实现相同的效果,它的意思是“提取我的 serverfix 并更新到远程仓库的 serverfix”。通过此语法,你可以把本地分支推送到某个命名不同的远程分支:若想把远程分支叫作awesomebranch,可以用 git push origin serverfix:awesomebranch 来推送数据。

5.2跟踪分支

从远程分支检出的本地分支,称为跟踪分支(tracking branch)。跟踪分支是一种和远程分支有直接联系的本地分支。在跟踪分支里输入 git push,Git 会自行推断应该向哪个服
务器的哪个分支推送数据。反过来,在这些分支里运行 git pull 会获取所有远程索引,并把它们的数据都合并到本地分支中来。

在克隆仓库时,Git 通常会自动创建一个 master 分支来跟踪 origin/master。这正是git push 和 git pull 一开始就能正常工作的原因。当然,你可以随心所欲地设定为其它
跟踪分支,比如 origin 上除了 master 之外的其它分支。刚才我们已经看到了这样的一个例子:git checkout -b [分支名] [远程名]/[分支名]。如果你有 1.6.2 以上版本的 Git,
还可以用 --track 选项简化:
$ git checkout --track origin/serverfix
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
Switched to a new branch "serverfix"

5.3删除远程分支

    如果不再需要某个远程分支了,比如搞定了某个特性并把它合并进了远程的 master 分支(或任何其他存放稳定代码的地方),可以用这个非常无厘头的语法来删除它:git push [远程名] :[分支名]。如果想在服务器上删除 serverfix 分支,运行下面的命令:

$ git push origin :serverfix
To git@github.com:schacon/simplegit.git
- [deleted]
serverfix

6.衍合

6.1基本衍合

    改变分支线路，基本上有两种套路：merge and rebase，其中后者就是衍合。

    注意，rebase的意义在于将要rebase的分支改变其祖先节点，而merge不会改变原有的分支结构；rebase更容易形成线性提交历史。

git checkout experiment

git rebase master

    变成：

6.2更多有趣的衍合

   原来的分支关系如下：

    假设在接下来的一次软件发布中,你决定把客户端的修改先合并到主线中,而暂缓并入服务端软件的修改(因为还需要进一步测试)。你可以仅提取对客户端的改变(C8 和 C9),然后通过使用 git rebase 的 --onto 选项来把它们在 master 分支上重演:
$ git rebase --onto master server client
这基本上等于在说“检出 client 分支,找出 client 分支和 server 分支的共同祖先之后的变化,然后把它们在 master 上重演一遍”。是不是有点复杂?不过它的结果,如图非常酷:

$ git checkout master
$ git merge client

$ git rebase master server

$ git checkout master
$ git merge server

6.3衍合的风险

呃,奇妙的衍合也不是完美无缺的,一句话可以总结这点:
永远不要衍合那些已经推送到公共仓库的更新。