2019-01-03 git 代码管理

个人的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,然后在这个分支上立即打一个包,给线上使用即可。

你可能感兴趣的:(2019-01-03 git 代码管理)