git初探-经典案例

    继续上次所说，来个经典案例吧～ 有了它可以更好的帮助我们去理解git。

1. 开发某个网站。

2. 为实现某个新的需求，创建一个分支。

3. 在这个分支上开展工作。

正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。 你将按照如下方式来处理：

1. 切换到你的线上分支（production branch）。

2. 为这个紧急任务新建一个分支，并在其中修复它。

3. 在测试通过之后，切换回线上分支，然后合并这个修补分支，最后将改动推送到线上分支。

4. 切换回你最初工作的分支上，继续工作。

    那么假设我们现在已经有了个工作流（master），为了新的需求，我们需要开设新开设一个分支，并切换到当前分支上（git checkout -b iss53），整个分支状态如下图所示，哈哈～ 是不是感觉图很眼熟，没错，就是你想的那样的

        然后我们在iss53的分支上进行我们新需求的编写并进行提交（commit），得到如下图的一个状态。

        突然，你接到了个紧急电话需要对原始代码进行紧急修复，而新需求还未开发完成，那么怎么办呢？这时，我们应切换到master分支，然后在当前版本下开设一个新的紧急分支，进行问题修复，然后提交（commit）。这时我们的git仓库则会呈现如下的一个状态。

        我们可以看到，hotfix 与 iss53 都是基于master所开设的两个分支。当我们在分支（hotfix）进行完紧急修复后，并测试没有为题后，这时，我们再切换到master上将hotfix合并进来（git merge master）。

        由上图，我们可以发现，这次合并是一次快进（fast-forward）的操作，那么何为快进呢？由于当前 master 分支所指向的提交是你当前提交（有关 hotfix 的提交）的直接上游，所以 Git 只是简单的将指针向前移动。换句话说，当你试图合并两个分支时，如果顺着一个分支走下去能够到达另一个分支，那么 Git 在合并两者的时候，只会简单的将指针向前推进（指针右移），因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进（fast-forward）”。

    

        现在我们的git仓库为上图所示，下面我们只需要将master上的最新代码提交到远程仓库就好（git push origin master:<远程分支名>），一般项目，我们可能并没有master的权限，可能需要我们将本地的master分支推到远程的一个开发分支上，当然最简单的做法是在本地开设一个与远程分支名相同的分支做为主分支，这样当我们在push时，直接git push 即可。

        好了，现在我们已经将紧急的需求处理完并且上传，那么hotfix这个分支我们也就不再需要了，下面直接将它删除就好（git branch -d hotfix），最后我们会得到一个清晰的代码库。然后我们继续在iss53分支上进行我们新的需求，直到新需求编写完成。

    

        最后，我们将已经开发完了的新需求合并到master上，并将最新代码提交到远程仓库。

       可以看出这次合并跟上一次合并有所不同，由于，master 分支所在提交并不是 iss53 分支所在提交的直接祖先，Git 不得不做一些额外的工作。 出现这种情况的时候，Git 会使用两个分支的末端所指的快照（C4 和 C5）以及这两个分支的工作祖先（C2），做一个简单的三方合并。

       最后，我们将得到如上图一样结构的代码库，这时再将master上的代码推送到远程分支即可。

       到此，我们的案例已经说完，从中我们发现，在这个开发工程中，master就像是一条河流的主线，无论你有多少个分叉，分叉上又有着怎么样的风景，到最后都会汇集成一条河流。

       那么以上便是我对于最近几天学习git的一个不成熟的总结，当然还有很多不足或是错误或是没涉及到的地方，欢迎大家留言指正。