近期项目中代码管理学习

     之前项目用的都是SVN进行代码管理的，最新的两个项目开始用git了，很早之前就开始接触git，但是一直没有正规的使用过，所以对git的命令并不是很熟悉，基本上的命令都是使用诸如clone、checkout、add、commit之类的命令。没有使用过创建分支（branch）和打tag之类的操作，目前项目中经常出现一种情况：项目开始的时候我们都在master分支上开发，然后等到一个阶段完成之后我们会发布这个版本，然后再创建一个develop分支，接着在develop分支上开发，然后对master分支发布，打tag，接着再继续在develop分支上开发，但是在开发过程中之前发布的版本可能出现一些bug，这时候需要紧急的修复。

     在当前的项目中，我逐渐开始接触到了项目中的代码管理，我们一般情况是保持三个分支：master分支，release分支和develop分支，master分支上的代码始终是稳定的，也就是当前最新发布的版本，release分支上的代码是给QA部署使用的，开发人员不能修改；开发只能够向develop分支上提交代码，然后自测完成之后再将develop上的代码merge到release分支上通知QA部署QA环境并且测试，当QA测试完成之后可以发布的时候再将release分支上的代码merge到master，之后可以将master分支上的代码构建，发布，再对当前发布的版本打tag。

     这样的一套流程中，当出现上面的问题时需要基于之前发布的版本进行紧急修复，这是就在master上拉取一个分支，因为master上的代码就是当前发布版本的代码，例如称为XXX-hotfix分支，然后在这个分支上做修复，修复完成之后再将该分支合并到release中由QA部署测试，成功之后还需要将这个版本再合并到master上和develop上。然后再对master上的分支打tag，构建发布。

     所以在当前的代码管理中一般会存在3个分支，最多存在一个hotfix分支，master分支上的代码总是当前上线版本的代码，开发只能够在develop分支上提交代码，所以冲突基本上都是在提交develop时候产生的，develop上合并到release和master上的时候基本上都可以自动合并的，当然如果存在多个开发版本的情况需要再进行讨论。

     以前项目中没有这么规范的流程，基本上也都是一个人开发，然后提交完成之后就交给QA测试了，没考虑到这些规范，当然随着规范的建立也多也一些繁琐的交互，但是这样长久下来还是效率比较高的。

     最后今天在使用git的时候不小心出现的一个问题，当我在hotfix分支上开发测试完成之后需要merge到develop分支和master分支上，当前我的git bash处于develop分支，我本来想pull一下最新的版本，却写成了git pull origin hotfix，这样子就把hotfix分支上的内容合并到了develop上，其实这个操作和merge差不多，然后我执行git push origin develop之后发现了develop上的最后一次提交的message是这样的：Merge branch 'hive-hotfix' of https://xxx.git.com.cn/git/xxx/xxx into develop。这个commit的message应该是git自动生成的，这就意味着当我把另外一个分支pull到当前的分支上之后执行了代码合并操作并且将本次合并之后的内容commit了。然后吸取了教训，切换到master分支，再次merge hive-hotfix分支，然后再push origin master，查看master上的commit记录发现在hive-hotfix中的提交记录也都提交上去了。

     

    所以在merge的时候不仅仅是代码的merge，还是提交每一个的commit，但是直接执行pull的时候则不会，因此下次需要警惕，一定不能在一个分支上pull另外一个分支的内容，而是用merge！