人的目标真的是阶段性的，总是一段时间清晰的知道自己想干什么，到了下一个阶段，又会去想这么做是不是最好的选择，最开始来上海的时候，觉得只要可以写代码就很开心，到现在会有一些‘体力活’感觉难受，而且随着对项目理解的加深，会发现，现在项目里面用到的东西是很陈旧的技术，但是我人轻言微没有办法去做什么改变和调整。自己很想学新的东西，可以用于分布式管理项目的Git.还有优秀的JS框架，新的编程思想，对JS的深层理解。这些东西都在吸引我。总觉得时间不够。感叹自己浪费是时间太多，醒的有点晚，但凡事总没有早知道。

回头想想，每个人都应该越活越成熟，但是人都在慢慢变得不知道自己真正想要的是什么，因为在变成熟的过程中，对成熟的定义也一直在变。那就选一条你觉得你应该坚持下去的路，走到黑吧。虽然我已经很黑了。

学习内容：

• 什么是分支？
• 新建，合并分支

什么是分支?

需要知道这个问题的答案，那首先要知道Git是怎么样的一种项目管理系统，这里引用官方文档的一句话：
  "Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异."

  从图上可以看到，Git只关心那些被修改的文件，其他没有变动的文件实际都只保存了一个指向这个文件的索引（指针）
  在回忆过这一个概念之后，可以开始看看branch在Git这样的管理模式中到底扮演着什么样的角色。
  在我们执行类似于下面这样的代码时：

$ git add Readme.md
$ git commit -m "new branch"

添加文件的add指令，会对每一个文件计算校验和（即SHA-1 哈希字串），然后把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 类型的对象存储这些快照），并将校验和加入暂存区域。
  而commit指令，会产生一个commit对象，这个commit对象包括了指向，在这次提交之前，由每个子目录形成的树对象（这个树对象是为了让你在提交过这次内容之后还可以重现提交之前的状态）的指针。除此之外，commit对象中还包含本次提交的作者等相关附属信息，包含零个或多个指向该提交对象的父对象指针：首次提交是没有直接祖先的，普通提交有一个祖先，由两个或多个分支合并产生的提交则有多个祖先。
  如下图：

上面这种情况更多是对应，我们首次提交更新。
  如果我们第一次提交的基础上，进行了修改，然后准备进行第二次提交。这时候情况会跟上面的图有所不同。此时的commit对象除了包含上面所说的这些信息，还会包含一个指向前一个commit对象的parent指针，如下图：

在明白了commit对象之后，我们就很好理解分支的概念了。所谓分支就是指向一个commit对象的指针（默认这个 分支的名称是master）：

这个指针是会根据你的更新一直移动的，一直指向你最新的这次更新。
  其实这很好理解，就拿自来水管道来打比方，比如现在有一根自来水管道经过A,B,C三个小区：
  A是最新通过的小区，C是最后的。
  那么如果有一天我们想新建一个线路到D小区。
  但是BD的距离比CD距离更小。
  那我们可以把这个指针指向B小区，从B小区动工然后修一条线路到D小区。

如果我们想在当前位置新修一条管道出去呢，用到指令：

$ git branch testBranch

现在我们已经修好了一条可以通道别的地方的管道， 接下来，我们得把工人都叫过来，开始在这条新的管道上工作。
  针对上面这个情况，Git里面定义了一个head指针，用来指向当前我们工作的分支管道，其实就相当于当前分支的别名。现在我们把这个head指针指向我们新建的testBranch指针

$ git checkout testBranch

这时候，我们的项目就像下面这张图一样：

然后我们在新的testBranch这个分支上新建了一个项目文件。比如说ReadMe.md

$ vim ReadMe.md  #新建ReadMe.md文件
$ git commit -a -m "Created the ReadMe.md " #提交我们刚刚新建的文档到testBranch分支

这样操作结果如下：

我们可以很清楚的看到，这是我们的testBranch分支已经往最前的位置移动，如果此时我们再切换到master分支，同样也新建一个文件。那就会产生一个分叉。

$ git checkout  master
$ vim ReadMeCopy.md
$ git commit -a -m "Created the ReadMeCopy.md"

结果如图:

关于第一小段"什么是分支?"官方的例子到这里结束了。那么，分支到底是什么，跟其他的版本控制工具，到底有什么区别？

分支的实际内容，是一段地址。地址指向一个commit对象，而commit对象中包含的是：
  1. 指向 在这次提交之前，由每个子目录形成的树对象 的指针。
  2. 本次提交的作者等相关附属信息。
  3. 包含零个或多个指向该提交对象的父对象指针。（第一次提交是没有的）

跟其他的版本控制工具的区别在哪呢？（个人见解）
  1. 在Git中，我们可以很轻易的回到之前的历史版本，我们只需要切换分支，实际上也就是把head指针移动到其他的分支上。
  而其他类型的版本控制工具，会把整个分支的文件备份到不同的目录下。如果我们要切换过去，就必须把这个分支上的所有文件同步到本地。
  2. 团队合作，我们可以让不同的同事，在同一个parent分支上新建他们自己的分支，他们可以随意提交代码到自己的分支，而其他人不会受到影响。只有在将来合并的时候再去处理有冲突的地方。
  如果是用SVN，每次你提交之前，都需要先update服务器上的代码，然后再commit，如果这时候有冲突，那你就不得不停下来先解决冲突的问题，在继续开发。实际上很有可能这个冲突可能已经分配给其他的同事去处理修改了。但是你并不知道。所以你现在不改也不行，改了有可能会影响到其他人的工作。（git允许你先把你要实现的都实现，最后大家都做好了，再来讨论代码的合并删减）。

新建，合并分支

在上一段的末尾，其实我们已经聊到了这个问题。在我们的项目中如果有了诸多分支之后，我们如何来对有冲突的分支进行合并呢？

首先我们创建一个新的项目，然后在这个项目master分支上新建一个iss53分支和hotfix分支用来修复不同的问题。

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit     (master)
$ git branch iss53#创建分支iss53
Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master)
$ git branch hotfix#创建分支hotfix
Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master)
$ git branch#显示当前所有分支
  hotfix
  iss53
* master

现在我们切换到hotfix分支上，假设我们需要解决hotfix这个问题就是需要在hotfix上新建一个文件。

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master)
$ git checkout hotfix#切换到hotfix分支
D       README.md
A       README.txt
D       READMORE
Switched to branch 'hotfix'

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (hotfix)
$ ls#显示当前目录下的文件
gitignore  README.txt

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (hotfix)
$ vim hotfix.txt#创建文件hotfix.txt

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (hotfix)
$ ls#显示创建后的结果
gitignore  hotfix.txt  README.txt
        Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (hotfix)
$ git add hotfix.txt #将新建的文件加到暂存区
warning: LF will be replaced by CRLF in hotfix.txt.
The file will have its original line endings in your working directory.

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (hotfix)
$ git status#查看暂存区
On branch hotfix
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        renamed:    README.md -> README.txt
        deleted:    READMORE
        new file:   hotfix.txt


Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (hotfix)
$ git commit -m"add hotfix.txt"#提交暂存区文件
[hotfix b75aa14] add hotfix.txt
 3 files changed, 1 insertion(+), 12 deletions(-)
 rename README.md => README.txt (100%)
 delete mode 100644 READMORE
 create mode 100644 hotfix.txt

现在就可以看到我们已经成功创建hotfix.txt这个文件到branch Hotfix下,并且已经成功提交。按照我们规定的假设，现在hotfix这个问题已经解决了。那么我们来把hotfix分支和master分支合并到一起。

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (hotfix)
$ git checkout master      #先切换到master分支
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master)
$ git merge hotfix       #合并master和hotfix分支
Updating 7bd6f76..b75aa14
Fast-forward
 README.md => README.txt |  0
 READMORE                | 12 ------------
 hotfix.txt              |  1 +
 3 files changed, 1 insertion(+), 12 deletions(-)
 rename README.md => README.txt (100%)
 delete mode 100644 READMORE
 create mode 100644 hotfix.txt

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master)
$ git branch -d hotfix#删除多余的hotfix分支
Deleted branch hotfix (was b75aa14).

觉得这里有必要贴上官方文档的一句话：

请注意，合并时出现了“Fast forward”的提示。由于当前 master分支所在的提交对象是要并入的 hotfix 分支的直接上游，Git 只需把 master 分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。

现在我们整个项目的状态应该是下面这张图所示：

我们暂时回到另一个分支“iss53”。这个分支跟之前我们已经删掉的hotfix是一个妈生的。然后我们也对它进行一些操作。比如新建一个iss53.txt文件。

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master)
$ git checkout iss53 #切换到分支iss53
Switched to branch 'iss53'

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (iss53)
$ vim iss53.txt #创建文件iss53.txt

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (iss53)
$ ls  #查看文件目录
gitignore  iss53.txt  README.md  READMORE

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (iss53)
$ git add iss53.txt #添加到暂存区
warning: LF will be replaced by CRLF in iss53.txt.
The file will have its original line endings in your working directory.

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (iss53)
$ git commit -m"add new file iss53.txt"#提交
[iss53 866f987] add new file iss53.txt
 1 file changed, 1 insertion(+)
 create mode 100644 iss53.txt

这一步结束之后，我们看看项目结构：

这时候，我们可以看到，iss53跟master已经不是直接的父子关系了，他们有个共同的父节点C2.也就是我们在创建hotfix分支和iss53分支之前的master。然后我们要对这两个分支进行合并。

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (iss53)
$ git checkout master#切换到master分支
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master)
$ git merge iss53#合并分支iss53
error: Empty commit message.
Not committing merge; use 'git commit' to complete the merge.

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master|MERGING)
$ git commit -m"we try to merge the iss53 to master"#提交&添加提交说明
[master a723ad4] we try to merge the iss53 to master

Dendoink@QELRM4A8Y4JCC8E MINGW64 /e/GITPUSH/moretestaboutgit (master)
$ ls#查看结果
gitignore  hotfix.txt  iss53.txt  README.txt

直接引用原文的话:
   这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）（见图 3-17）。这个提交对象比较特殊，它有两个祖先（C4 和 C5）。
  值得一提的是 Git 可以自己裁决哪个共同祖先才是最佳合并基础；这和 CVS 或 Subversion（1.5 以后的版本）不同，它们需要开发者手工指定合并基础。所以此特性让 Git 的合并操作比其他系统都要简单不少。

结果如图:

如果合并时遇到问题呢？

原文档中会有例子，但是我一直尝试重现没有成功，每次我把新的branch里面的某个文件（master中也有这个文件）修改之后，Git都会在我的进行merge的时候直接用新的文件替换旧的。这姑且算是有个没弄明白的地方吧。这里不对官方文档中的处理方式进行描述。

由于篇幅的问题，我把关于Branch的其他内容放到了下一篇日志里面。先到这里。