个人的git代码管理心得：
1.我们一般不会用到分支branch。只有一种场景下我们需要开多个分支：
我们一边在开发新需求，一边要修改线上版本的bug。
所以，我们需要至少两个分支：
dev下一版本开发分支，专门负责开发需求
prd线上版本修复分支，专门修复线上bug。（这里我把master当成prd使用，这样做是因为：master本身也是一个分支，打包默认都是master，测试也必须测试masyer上的分支的代码，所以master完全可以当做prd）
这里面就有关于合并的艺术了。
第一：开发需求在dev分支
第二：修改线上bug和发版打tag在prd分支上。
这样，在sourceTree上就会出现分叉点。
假设：提交日志如下：
branch dev ： 开发需求1
branch master ： 修复bug1
然后到了合并这一天，在sourceTree上操作步骤如下：
本地分支选择master ，在sourceTree上选取远端的dev代码提交节点，进行代码合并。提交日志为：branch master ：合并远端dev代码到本地master分支，解决冲突
接着，测试介入，开发人员在master上解决测试提出的bug，日志如下：
branch master ：解决测试人员反馈的bug
最后，测试完毕，打包，上线，发版，打tag
下一版本即将开发前，我们需要把dev更新到最新，这里面又出现一次合并：
日志如下：
branch dev ：合并远端master代码到本地dev分支，解决冲突，开启下一阶段的需求开发
以上所有过程，只有两个分支，一个版本开发周期里，只会发生两次代码合并的过程。减少了合并的操作，和测试人员的工作。
疑问1：dev合并到master后，如果线上版本出bug怎么办？
1.不严重bug，那就在dev阶段解决，然后一期上线。
2.严重bug：立即拉取一个新分支，我叫它：紧急修复分支emergency
在这个分支上，我们使用代码回滚，然后修复bug，然后在这个分支上立即打一个包，给线上使用即可。
网友评论