Concernant les solutions de rechange
git checkout iphone -b iphone31
git merge master
et
git checkout master -b iphone31
git merge iphone
ils auront la même facilité ou la difficulté, c'est comme arguant qu'un verre est à moitié plein ou à moitié vide.
L'arbre de Version de la perception
La façon dont nous regardons la version arbres sont en quelque sorte nos arbitraire de la perception.
Disons que nous avons une version de l'arbre comme suit:
A----------+
| |
| |
\_/ \_/
B X
| |
| |
\_/ \_/
C Y
|
|
\_/
D
|
|
\_/
E
Et disons que nous voulons faire une nouvelle version Z extrait de Y'
sur la base des changements de C à E, mais pas y compris les modifications apportées à partir de
De A à C.
"Oh, ça va être difficile, car il n'y a pas de point de départ commun."
Et bien pas vraiment. Si on se contente de placer les objets un peu différemment
dans le graphique de mise en page comme ceci
/
C+---------+
| \ |
| |
\_/ |
D B
| / \
| |
\_/ |
E A
|
|
\_/
X
|
|
\_/
Y
maintenant, les choses sont en train de regarder prometteur. Notez que je n'ai pas
changé toute relation envoyé ici, les flèches pointent tous de la même façon que
dans l'image précédente et la version A est toujours le socle commun.
Seule la mise en page est modifiée.
Mais maintenant trivial d'imaginer un autre arbre
C'---------+
| |
| |
\_/ \_/
D B'
| |
| |
\_/ \_/
E A
|
|
\_/
X
|
|
\_/
Y
d'où la tâche serait de fusionner la version E normalement.
De sorte que vous pouvez fusionner tout ce que vous voulez, la seule chose qui influence
la facilité ou la difficulté est l'ensemble des modifications effectuées entre où
vous sélectionnez un point de départ ou de base commune et où vous fusionner pour.
Vous n'êtes pas limité à l'aide du point de départ naturel de la votre
gestion des versions de l'outil de suggérer.
Cela pourrait ne pas être simple avec certains systèmes de contrôle de version/outils,
mais si tout le reste échoue, il
n'est rien qui vous empêche de le faire manuellement par
de vérifier la version C et enregistrez le fichier fichier1,
de vérifier la version E et enregistrez le fichier en tant que fichier2,
de vérifier la version Y et enregistrez le fichier en tant que fichier3
et exécutez kdiff3 -o merge_result file1 file2 file3.
Réponse
Maintenant, pour votre situation spécifique, il est difficile de dire exactement ce qu'
stratégie qui permettra de produire le moins de problèmes, mais
si il y a beaucoup de changements qui créent une sorte de conflit, il
est probablement plus facile de diviser et fusionner les petites pièces.
Ma suggestion serait que
puisqu'il y a 32 s'engage entre la dernière et l'iphone,
vous pourriez par exemple commencer par une ramification de maître, et
fusion dans les 16 premiers commits. Si cela s'avère
être trop de difficultés, de revenir et d'essayer de fusionner les 8 premiers commits.
Et ainsi de suite. Dans le pire des cas, en fin de fusion de chacun des 32 commet un par un,
mais il serait sans doute plus facile que d'avoir à gérer tous les
le cumul des conflits en une seule opération de fusion (et
dans ce cas, vous travaillez avec un vraiment divergentes de la base de code).
Conseils:
Tirage sur papier une version de l'arbre et de la note avec les flèches de ce que vous voulez
de fusion. Rayez les choses comme elles le sont en fait si vous fractionnez le processus
en plusieurs étapes. Cela vous donnera une image plus claire de ce que vous voulez
à atteindre, ce que vous avez fait et ce qui est à gauche.
Je peux vraiment recommander KDiff3, c'est un excellent diff/merge tool.
