Background: Assume that the code is refactored from the master 1.0 version, and the new branch is called v2. During the reconstruction process, master 1.0 is constantly being merged with new modifications or bug fixes. By the time v2 development was completed, there were too many differences and conflicts between the two branches.
In such a scenario, how can we better release master 2.0?
In practice, when refactoring code, how can we better avoid a large number of conflicts?
Hello, there is no simple way to deal with the flushing out during the merger, and the corresponding business personnel may have to deal with it one by one.
There are some objections to the way of refactoring. During the refactoring process, the master has to deal with bugs and release functions. Why doesn't v2 merge in time?
If master 1 is officially released every time, master 2 can be merged in time, and the amount of conflicts will be reduced!
We also encountered similar problems.
For example, there is a stable version stable, and there is a directory below it called fs
Then there is a development branch develop, and there is a directory below it called fsv2
The new version is developed on develop, and the fs directory has been abandoned. The relevant fs codes have been modified in the fsv2 directory.
At this time, a problem arises that requires hotfixing immediately. The hotfix is done on the stable fs. How can we merge this modification into the fsv2 directory of develop? We actively backport the develop branch every time we hotfix. , implement the new patch on the new branch.
This is true for hotfix. For the development of large features, stable is generally not needed. If both sides need to be done, it is best to put it in a common directory and make it into a more general module before merging. .
This is my own experience, I may be lagging behind, please give me your advice.
Generally speaking, if the refactored part has not been modified in master 1.0, of course there will be no problem.
If there are new modifications to the refactored part, the people doing the two tasks must communicate well, otherwise there will definitely be problems during the merge.
But usually, there is no need to refactor and modify the same part of the code at the same time. If you really want to do this, the two tasks do not need to be completely synchronized. You can refactor one day, modify one day, and merge branches repeatedly.