背景：假设从 master 1.0 版本新建分支重构代码，新分支叫 v2。 重构过程中，master 1.0 不断有新的修改或 bug 修复合并。等到 v2 开发完成时，两个分支之间差异太多，冲突也很多。
这样的场景下，如何处理才能比较好的发布 master 2.0？实践中，当重构代码时，如何操作才能比较好的避免大量冲突的出现？
你好，如何处理合并时的冲出，没有什么简单方式，可能就得相应业务人员逐条处理了。就重构的方式有些异议，重构过程中master有bug处理、功能发布。v2为什么不及时合并呢？若master 1每次正式发布，master 2都能及时合并，冲突了量就会减少了吧！
我们也遇到类似问题.比如有一个稳定版本stable,下面有个目录是fs然后以一个开发分支develop,下面有个目录是fsv2
新版本都是在develop上开发,并且fs目录也已经废弃,相关fs的代码都在fsv2目录下修改了.
这个时候出现一个需要立刻做hotfix的问题,hotfix是在stable的fs上做的,那develop的fsv2目录怎么才能把这个修改merge进去呢,我们是在每次hotfix的时候主动对develop分支进行backport,把新的patch在新分支上实现一次.
对于hotfix是这样,对于大的feature的开发,相对而言stable一般是不需要了,如果两边都需要做,那最好就是放在一个公共的目录下,做成较为通用的模块之后进行merge.
这是我自己的经验,可能比较落后,还请大家指教.
一般而言，如果重构的部分在master 1.0没有被修改当然不会出现问题。
如果重构的部分还有新的修改，那么进行这两项任务的人员必须沟通好，否则在merge时肯定出现问题。
不过通常情况下，不需要一边重构，又一边修改同一部分代码吧。真要这么做，两项任务也不需要完全同步进行，可以重构一天，修改一天，反复合并分支。
你好，如何处理合并时的冲出，没有什么简单方式，可能就得相应业务人员逐条处理了。
就重构的方式有些异议，重构过程中master有bug处理、功能发布。v2为什么不及时合并呢？
若master 1每次正式发布，master 2都能及时合并，冲突了量就会减少了吧！
我们也遇到类似问题.
比如有一个稳定版本stable,下面有个目录是fs
然后以一个开发分支develop,下面有个目录是fsv2
新版本都是在develop上开发,并且fs目录也已经废弃,相关fs的代码都在fsv2目录下修改了.
这个时候出现一个需要立刻做hotfix的问题,hotfix是在stable的fs上做的,那develop的fsv2目录怎么才能把这个修改merge进去呢,我们是在每次hotfix的时候主动对develop分支进行backport,把新的patch在新分支上实现一次.
对于hotfix是这样,对于大的feature的开发,相对而言stable一般是不需要了,如果两边都需要做,那最好就是放在一个公共的目录下,做成较为通用的模块之后进行merge.
这是我自己的经验,可能比较落后,还请大家指教.
一般而言，如果重构的部分在master 1.0没有被修改当然不会出现问题。
如果重构的部分还有新的修改，那么进行这两项任务的人员必须沟通好，否则在merge时肯定出现问题。
不过通常情况下，不需要一边重构，又一边修改同一部分代码吧。真要这么做，两项任务也不需要完全同步进行，可以重构一天，修改一天，反复合并分支。