【Git之窗】（五）Git分支管理的一个实例

   上一篇博客中介绍了Git分支管理的基础概念，这篇博客模拟一个实际场景来分析下为什么要提倡要“频繁”地使用Git分支。

   -------------------------------------------

   人物：

   一名姓“程”，名“序员”的单身程序员，29岁，黑框眼镜、格子衫、牛仔裤、运动鞋、双肩包……

   ------------------------------------------

   场景：

   1、开发某“**云平台”项目。

   2、为了实现某个新的需求，创建一个分支“iss53”。

        

            3、在这个分支上继续展开工作，并且执行了一次commit操作，此时"iss53"分支已经指到了C3版本的快照上。

             

        之后，“序员”仍然在继续工作……

  ---------------------------------------------------------------

   突发情况：

   “序员”突然接到一个电话说线上版本有个很严重的bug需要紧急修补，前提是生产服务器上的程序已经发版，此时你该怎么办？要知道，此时你已经在上线的版本上写了一些新的功能，但是没有测试，你会怎么办？

   ---------------------------------------------------------------

    我的解决方案：

   （1）Git方案

    1、提交iss53上对新需求开发的版本， 之后checkout到master分支上面，这个时候我的工作目录中的内容已经和线上那个版本的代码一模一样了

    2、我在master的基础上，新建“hotfix”分支，此时hotfix分支指向了C4版本的代码：

       

            紧接着，在hotfix分支上修改这个线上的bug，此时序员已经加班到了凌晨1点钟……

    突然间，bug消失了，紧接着测试也通过了，太爽了！

   3、通过“git rebase”或者“git merge”命令，把hotfix分支合并到master分支上面，如图：

            

          4、此时可以通过命令“git branch -d hotfix”删除掉hotfix分支了，并且通过"git checkout iss53"命令切换到了iss53分支，继续新需求的开发工作，如图：

               

           如果想要把解决线上bug的修复代码也同步到"iss53"上面，执行“git rebase master”，此时的“iss53”分支已经是兼具“解决了线上bug”同时“在开发新功能”的一个分支了。

   （2）SVN方案

    由于已经写了一部分新需求的代码，首先通过“与资源库同步”按钮，找到最近在每一层、每一个模块里修改过的代码，做好备份后，“还原”到之前的代码版本，此时与线上发版的代码一模一样了，之后解决bug、测试、打包、发版。

    紧接着，将之前做修改的那部分代码提取出来，再copy到当前工作目录当中，测试、打包、发版。

    比较针对这个突发问题的解决，很显然Git的使用要优于SVN的解决方案，所以，建议使用前者。