Git——分支管理

一、分支
  在版本控制过程中，使用多条线同时推进多个任务。

  Git在初始化之后会有一个master分支，或者称为主干。在开发时不想对主干造成污染，就需要开辟新的分支。新的分支创建出来的时候和主干是一致的。各个分支是彼此独立的，这样在某一个分支因为某个原因开发失败时可以直接将该分支删除，而不会影响主干和其他分支，方便试错。当某个分支开发完成并测试没问题之后就可以将其合并到主干，也就形成主干的一个大的版本升级。在主干上也有可能会有bug出现，此时就需要一个hot_fix的热修复分支，修复之后立即合并到主干，这样主干就产生一个小的版本升级。
  分支的优点：
    ①同时并行推进多个功能开发，提高开发效率
    ②各个分支在开发过程中，如果某一个分支开发失败，不会对其他分支有任何影响。失败的分支删除重新开始即可，方便试错

二、分支操作
 1、查看分支：

git branch -v

 2、创建分支：git branch 分支名，分支在创建出来之后，内容会和master保持一致

 3、切换分支：git checkout 分支名

 4、合并分支：将其他分支合并至master
  ①编辑hot_fix分支上的文件

  ②合并分支：在合并之前须将当前所在分支切换至master(合并到哪个分支就切换为哪个分支，当然也可以合并至其他分支)，然后执行git merge 分支名称命令

 TIP：合并分支的时候也可以使用 git rebase 命令，rebase会保留你的提交历史，merge仅是将你最终修改的内容和master上的内容合并起来，push后，仅有merge这一次的comment。

三、分支合并冲突的解决
  在合并分支时是有可能产生冲突的，此时就需要解决冲突。比如：在多个分支上同时修改同一个文件，在合并时有可能在相同的行在多个分支上的内容是不一样的，这就是冲突，需要人去干预冲突的处理，因为Git是无法知道应该怎么取舍的。
 1、合并分支

 2、查看和编辑冲突文件，解决冲突：将多余的内容删除

 3、查看状态：

 4、执行git add命令

 5、执行git commit命令完成冲突的解决：分支的MERGING标记也没有了

  注意:在解决完冲突最后提交的时候一定注意不要带具体的文件名

四、生产中如何使用分支

 在正式的生产中，需要提交的代码在开发、测试、准生产(可能没有)都没有问题之后才会上生产环境。为了开发任务齐头并进，尽可能的将不同的工作任务放在不同的开发分支上，对于Git来说创建一个分支的开销是很小的。
 如上图所示：需要一个生产分支(master)、一个临时的热修复分支(bugfix，该分支使用完之后即可删除)、一个开发基线分支(dev，即测试分支)和若干个开发分支(feature)。
 整体步骤：
  ①项目经理：初始化master分支，在master分支上创建开发基线分支dev，再在dev上创建多个工作任务分支feature1、feature2…；如出现紧急bug，会在master上创建紧急热修复分支bugfix，待bug修复后由测试人员将该bugfix分支打包测试，无问题后再将bugfix分支的变动合并至master，并同步合并至dev，再同步(merge)至各个开发分支，然后将bugfix分支删除
  ②开发人员：开发人员从开发分支(如feature1，或其他开发分支)检出项目至本地，注意不要在检出的分支上进行代码编写等修改操作，要保证该检出到本地的分支和远程分支保持一致，而是在本地在该检出的分支上再创建一个新分支(如feature1_0412)，在新创建的分支(feature1_0412)上进行代码编写等工作，开发完成之后将新分支(如feature1_0412)的代码提交并合并至本地检出的分支(feature1)，然后将本地检出的分支(feature1)的代码推送至远程feature1，另外要养成一个习惯：经常性的从远程开发分支pull代码至本地开发分支，再merge至创建的新分支，以避免在push的时候产生冲突。在本地新创建的分支上编写代码而不是直接在检出的分支上编写代码有很多好处，比如说你在开发一个大任务，但是在大任务完成之前又来了一个小任务而且很紧急，假如你是在检出的分支上直接编码，那这时你肯定已经修改或增加了很多文件，但这些文件和小任务很可能没有什么关系，那你怎么先完成这个小任务呢？只能再重新检出在一个新的工作空间来完成了，这样是比较繁琐的。当然Git也提供了git stash 、git stash list 和 git stash apply 来实现更改的暂存和恢复，使用git stash 和git stash apply也能解决这个问题，但这是在你没有在本地commit修改的前提下，因此最好还是新开一个本地分支，这对于git来说开销是极小的。

  ③测试人员：开发人员将本地分支的修改推送到远程的开发分支(如远程feature1)之后，对于开发人员来说工作就已经完成了，下面就是测试人员对开发人员提交的代码进行测试。
  这里有一个权衡问题：
   1️⃣测试人员先把远程开发分支(如feature1，此时该分支可能有多个开发人员作出的修改，因为多个人可能在同一个开发分支上开发)合并到测试分支(dev)之后再打包发版测试，在无问题后合并至生产分支，然后在预生产环境下再次进行测试，没问题后发生产；以上说的是没有问题的理想状态(没有出现程序无法启动，或者还存在缺陷)下，一旦合并至测试分支之后还有问题，就比较麻烦了，因为测试分支合并的可能不止一个开发分支，可能有很多个开发分支，这时从中去除那个错误的合并是比较麻烦的，所以我们要尽可能的保证测试分支的正确。因此最好不要采用这种方式；
   2️⃣将远程开发分支(如feature1)先打包发版测试，先测试这一个分支，如果这个分支有问题也不会影响太大，再让开发人员接着修改即可，在该分支无问题之后再将该分支合并至测试分支(dev)，再将测试分支进行打包发版测试，这个时候有问题的可能性就会小很多，在测试分支无问题后再将测试分支合并至生产分支(master)，再次打包发版在预生产环境下测试，测试通过之后发生产。这种方式相对要稳妥很多。
  ④运维人员：测试通过之后，会将master分支打包交给运维人员发生产。