让我们来看一个简单的分支新建与分支合并的例子，实际工作中你可能会用到类似的工作流。 你将经历如下步骤：
1.开发某个网站。
2.为实现某个新的用户需求，创建一个分支。
3.在这个分支上开展工作。
正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理：
1.切换到你的线上分支（production branch）。
2. 为这个紧急任务新建一个分支，并在其中修复它。
3.在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。
4.切换回你最初工作的分支上，继续工作。
假设正在项目中进行工作,并且在master分支上有了一些提交.
在master分支上提交的代码,但是公司使用的问题追踪系统中的 #53 问题
然后,你正在iss53分支上工作,并提交了一些代码.此时iss53分支正在向前推进.此时你本地的工作分支是iss53,所以head指向的是你的iss53分支的最后一次提交记录.
此时,你接到一个电话,有个紧急问题需要解决.此时,你讲你的iss53分支上做了一下commit.然后checkout master,切换到master分支,然后从master分支上重新切换出来一个分支叫hotfix.然后在hotfix中对紧急问题进行修复,然后作出commit.此时应该是这样子的
然后提交测试,测试完成,将hotfix分支的代码merge到master分支上,部署到线上.
此时,你执行了git merge hotfix,那么会显示出来
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
在执行合并的时候,出现了fast-forward(快进).解释一下:
由于hotfix所指向的提交记录C4,是在master分支指向的最后一次提交记录C2的直接后继.那么git在执行合并是直接将master分支的指向直接向前移动到C4提交记录,指向向前移动一下,因为这种情况,不存在分歧,即直接从master分支最后一次的提交记录中拉出来一个,然后再此后没有别的分支对该分支进行合并操作,不会产生任何需要解决的分歧,这样的合并方式就是fast-forward.
在紧急问题解决后,准备回到之前打断的工作中.此时你应该删除hotfix分支,因为不再需要它了.现在继续切换会iss53分支,继续解决问题.
此时可以看到,iss53分支上的一些提交记录C3 C5,还是基于C2提交的,但你master分支的最新内容已经指向到C4的提交记录中.所以,两种解决方案
1.将master分支merge到iss53分支
2.或者我们通常的做法是,将iss53分支上的内容修改完成后,将iss53分支merge到master分支.
假设,你现在修正完成了iss53的问题,将你的工作分支iss53合并到master分支.这个时候和之前将hotfix分支合并到master分支好像并不一样.iss53分支的源头在C2,并不是当前master分支所指向的最后一次提交,master分支所在的提交并不是iss53分支的直接祖先.git会使用两个分支的末端所指的快照C4 和 C5,以及这两个分支的工作祖先C2,做一个简单的三方合并.
和之前将master分支的指针向前推进到C4快照不同的是,git此次将本地三方合并的结果做了一个新的快照,并且自动创建了一个新的Commit提交记录,来使master分支指向它,这个被称作是一次合并提交.
有时候合并并不是如此顺利,在不同的分支中,对同一个文件的同一个部分进行了不同的修改,git则手足无措,不知如何干净的merge它们.在merge时,git会暂停,手动的去需要处理它们.
可以使用git status, 来查看哪些文件处理unmerge的状态.
