使用 git 时，在某个分支进行重构，和 master 分支差异过大，如何合并？

Question

背景：假设从 master 1.0 版本新建分支重构代码，新分支叫 v2。 重构过程中，master 1.0 不断有新的修改或 bug 修复合并。等到 v2 开发完成时，两个分支之间差异太多，冲突也很多。

这样的场景下，如何处理才能比较好的发布 master 2.0？
实践中，当重构代码时，如何操作才能比较好的避免大量冲突的出现？

Answer 1

Bonjour, il n'y a pas de moyen simple de gérer les débusquages ​​lors de la fusion. Vous devrez peut-être les gérer un par un par le personnel de l'entreprise correspondant.
Il y a quelques objections à la manière de refactoriser. Pendant le processus de refactoring, le maître doit gérer les bugs et publier des fonctions. Pourquoi la v2 ne fusionne-t-elle pas à temps ?
Si le master 1 est officiellement publié à chaque fois, le master 2 pourra être fusionné avec le temps, et le nombre de conflits sera réduit !

Answer 2

Nous avons également rencontré des problèmes similaires.
Par exemple, s'il existe une version stable stable, il y a un répertoire en dessous appelé fs
, puis il y a une branche de développement développer, et il y a un répertoire en dessous. il s'appelle fsv2

La nouvelle version est développée sur develop, et le répertoire fs a été abandonné. Les codes fs concernés ont été modifiés dans le répertoire fsv2.

À l'heure actuelle, il y a un problème qui doit être corrigé immédiatement. Le correctif est effectué sur le fs stable. Comment pouvons-nous fusionner cette modification dans le répertoire fsv2 de develop ? nous effectuons un correctif. Effectuons un backport et implémentons le nouveau patch sur la nouvelle branche.

C'est vrai pour le hotfix. Pour le développement de fonctionnalités volumineuses, stable n'est généralement pas nécessaire. Si les deux côtés doivent être effectués, il est préférable de le mettre dans un répertoire commun et d'en faire un module Perform plus général. fusionner.

C'est ma propre expérience, elle est peut-être en retard, merci de me donner vos conseils.

Answer 3

D'une manière générale, si la partie refactorisée n'a pas été modifiée dans le master 1.0, bien sûr il n'y aura pas de problème.

S'il y a de nouvelles modifications dans la partie refactorisée, les personnes effectuant les deux tâches doivent bien communiquer, sinon il y aura certainement des problèmes lors de la fusion.

Mais généralement, il n'est pas nécessaire de refactoriser et de modifier la même partie du code en même temps. Si vous voulez vraiment faire cela, les deux tâches n'ont pas besoin d'être complètement synchronisées. Vous pouvez refactoriser un jour, modifier un jour et fusionner des branches à plusieurs reprises.