开发git分支管理
在日常开发中，git分支管理是必不可少的。如何组织构建一个良好的git分支尤其重要，这里简单记录一下相关知识。
分支管理理解
常见分支
我们可以把git的分支想象成《西游记》里的角色，每个角色都有自己的身份和任务，但是他们之间也可以互相协作和交流。下面是一些常见的分支和对应的角色：
master分支：这是git的默认分支，它代表了项目的正式版本，也就是最终要交付给用户的产品。我们可以把它比作唐三藏，他是取经的主要人物，也是最终要把佛经带回东土的使者。
develop分支：这是一个用于开发的分支，它代表了项目的最新状态，也就是正在进行中的版本。我们可以把它比作孙悟空，他是唐三藏的大弟子，也是最有本事的战斗力，他可以在开发分支上尽情地施展自己的神通，然后在合适的时机，把成果合并到master分支上。
feature分支：这是一个用于开发新功能的分支，它代表了项目的一个特定需求，也就是一个独立的模块。我们可以把它比作猪八戒，他是唐三藏的二弟子，也是最爱吃喝玩乐的角色，他可以在feature分支上开发自己感兴趣的功能，然后在完成后，把功能合并到develop分支上。
bug分支：这是一个用于修复错误的分支，它代表了项目的一个特定问题，也就是一个需要改正的缺陷。我们可以把它比作沙悟净，他是唐三藏的三弟子，也是最沉默寡言的角色，他可以在bug分支上修复发现的错误，然后在解决后，把错误合并到develop分支上。
release分支：这是一个用于发布的分支，它代表了项目的一个稳定版本，也就是一个即将交付的产品。我们可以把它比作白龙马，他是唐三藏的四弟子，也是最忠诚有礼的角色，他可以在release分支上进行最后的测试和调整，然后在通过后，把版本合并到master分支和develop分支上。
我们先反向思考一个产品的形成：
- 首先开发最终目的是有一个项目产品，可以交付给用户使用的版本，这个就是正式版的
master主分支。 - 在发布正式版之前，还有一个最终测试版
pre-release分支，这上面最终通过测试，才会合并到master主分支进行发布。 - 那分支pre-release怎么来的呢，当然是我们日常开发更新来的，所以我们还需要一个
daily日常分支，用以我们日常开发整合测试 。 - 最后来说，日常分支肯定不止一个开发者维护，所以，我们再给每个开发者创建一个分支，也就是
个人分支，个人开发完成后，将代码同步到daily日常分支。 - 开发机：一般每个开发人员都会有一台，一般公司可能没有，毕竟人手一台服务器，开销还是挺大的。
接着我们便可以正向得出一般的开发流程：
- 自己分支开发，本地自测，如果有开发机，就直接部署个人分支即可，最终部署公共分支时再解决冲突
- pull daily最新的到本地，合并到daily（你也可以直接合到远程daily，这样就不用先pull daily了；pull daily的意图是不覆盖别人已经合到daily的代码）进行日常环境测试
- 合并到pre（pull的操作同daily一致）进行预发测试
- 合并到（pull的操作同daily一致）master，进行发版操作
分支冲突
开发中难免会遇到冲突，比如两个开发者同时开发修改同一个文件，那么很容易就产生冲突。
解决冲突：
- 一旦出现冲突，如果只是位置冲突，那么合并时两者代码都保留即可；
- 如果是代码修改点冲突，一定要和冲突对应分支的开发对齐，
分支合并举例
我有三个分支，分别是main,a,b，main是主分支，a和b都是从main分出来的，具体内容如下。
接下来，我将a分支的修改，合并到main分支。操作如下，
将当前分支切到main分支
checkout current branch 选择a分支合并到main分支，我们可以选择合并全部a提交（图1），或者合并指定提交（图2）
图1 
图2 冲突合并：这里由于之前我修改了这部分代码，所以提醒两次合并有冲突，需要手动进行合并，这里选择接受右边a的代码
冲突显示 
手动合并 最终，a所有的修改被合并到了main分支上。
最终结果
特别感谢好友 dragonyu的指导。