在当前的项目中，我逐渐開始接触到了项目中的代码管理，我们普通情况是保持三个分支：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。