Flux de travail Git Cherry-pick vs Merge

Question

En supposant que je sois le responsable d'un dépôt et que je veuille récupérer les modifications d'un contributeur, il y a plusieurs flux de travail possibles :

1. I cherry-pick chaque livraison du serveur distant (dans l'ordre). Dans ce cas, git enregistre le commit comme non lié à la branche distante.
2. I merge la branche, en tirant tous les changements, et en ajoutant un nouveau commit "conflit" (si nécessaire).
3. I merge chaque commit de la branche distante individuellement (encore une fois dans l'ordre), ce qui permet d'enregistrer les conflits pour chaque commit, au lieu de les regrouper en un seul.
4. Pour être complet, vous pourriez faire un rebase (même chose que cherry-pick ), mais je crois savoir que cela peut être source de confusion pour le contributeur. Cela élimine peut-être l'option 1.

Dans les deux cas 2 et 3, git enregistre l'historique des branches des commits, contrairement au cas 1.

Quels sont les avantages et les inconvénients d'utiliser l'une ou l'autre des deux méthodes ? cherry-pick ou merge méthodes décrites ? Je crois savoir que la méthode 2 est la norme, mais j'ai l'impression que résoudre un gros commit avec une seule fusion "conflictuelle" n'est pas la solution la plus propre.

Answer 1

Les deux sites rebase (et cherry-pick ) et merge ont leurs avantages et leurs inconvénients. Je plaide pour merge ici, mais cela vaut la peine de comprendre les deux. (Regardez ici pour une alternative, bien argumentée. réponse en énumérant les cas où rebase est préférable).

merge est préféré à cherry-pick et rebase pour plusieurs raisons.

1. Robustesse . L'identifiant SHA1 d'un commit l'identifie non seulement en lui-même mais aussi en ce qui concerne tous les autres commits qui le précèdent. Cela vous offre la garantie que l'état du référentiel à un SHA1 donné est identique dans tous les clones. Il n'y a (en théorie) aucune chance que quelqu'un ait fait ce qui ressemble à la même modification mais qui en fait corrompt ou détourne votre dépôt. Vous pouvez sélectionner des modifications individuelles et il est probable qu'elles soient identiques, mais vous n'avez aucune garantie. (Comme problème secondaire mineur, les nouveaux commits cherry-pickés prendront de l'espace supplémentaire si quelqu'un d'autre cherry-picke dans le même commit à nouveau, car ils seront tous deux présents dans l'historique même si vos copies de travail finissent par être identiques).
2. Facilité d'utilisation . Les gens ont tendance à comprendre le merge assez facilement. rebase est généralement considéré comme plus avancé. Il est préférable de comprendre les deux, mais les personnes qui ne veulent pas être des experts en contrôle de version (ce qui, d'après mon expérience, inclut de nombreux collègues qui sont très bons dans ce qu'ils font, mais ne veulent pas passer le temps supplémentaire) ont plus de facilité à fusionner.

Même avec un flux de travail lourd en matière de fusion rebase et cherry-pick sont toujours utiles pour des cas particuliers :

1. L'inconvénient de merge est une histoire encombrée. rebase empêche une longue série de commits d'être éparpillés dans votre historique, comme ils le seraient si vous fusionniez périodiquement les changements des autres. C'est en fait son objectif principal tel que je l'utilise. Ce que vous voulez être très attention, c'est de ne jamais rebase le code que vous avez partagé avec d'autres référentiels. Une fois qu'un commit est push ed quelqu'un d'autre pourrait avoir commis par-dessus, et le rebasage causera au mieux le genre de duplication discutée ci-dessus. Au pire, vous pouvez vous retrouver avec un référentiel très confus et des erreurs subtiles qui vous prendront beaucoup de temps à découvrir.
2. cherry-pick est utile pour échantillonner un petit sous-ensemble de modifications à partir d'une branche de sujet que vous avez décidé de rejeter, mais dont vous avez réalisé qu'elle contient quelques éléments utiles.

Pour ce qui est de préférer la fusion de plusieurs modifications à une seule : c'est tout simplement beaucoup plus simple. Il peut devenir très fastidieux de faire des fusions de modifications individuelles quand on commence à en avoir beaucoup. La résolution des fusions dans git (et dans Mercurial, et dans Bazaar) est très très bonne. Vous ne rencontrerez pas de problèmes majeurs pour fusionner même de longues branches la plupart du temps. Je fusionne généralement tout en une seule fois et seulement si J'obtiens un grand nombre de conflits si je fais marche arrière et relance la fusion au coup par coup. Même dans ce cas, je le fais par gros morceaux. Comme exemple très concret, j'ai eu un collègue qui avait 3 mois de changements à fusionner, et a obtenu quelques 9000 conflits dans une base de code de 250000 lignes. Ce que nous avons fait pour résoudre le problème, c'est de fusionner l'équivalent d'un mois à la fois : les conflits ne s'accumulent pas de manière linéaire, et le fait de le faire par morceaux donne lieu à loin moins de 9000 conflits. C'était encore beaucoup de travail, mais pas autant que d'essayer de le faire un commit à la fois.

Answer 2

À mon avis, le cherry-picking devrait être réservé aux rares situations où il est nécessaire, par exemple si vous avez effectué une correction directement sur la branche 'master' (trunk, branche principale de développement) et que vous vous êtes ensuite rendu compte qu'elle devait être appliquée également à 'maint'. Vous devriez baser le workflow soit sur la fusion, soit sur la rebase (ou "git pull --rebase").

N'oubliez pas qu'un commit cherry-picked ou rebased est différents du point de vue de Git (a un identifiant SHA-1 différent) que l'original, il est donc différent du commit dans le dépôt distant. (Rebase peut généralement gérer ce problème, car il vérifie l'identifiant du patch, c'est-à-dire les changements, et non l'identifiant du commit).

De même, dans git, vous pouvez fusionner plusieurs branches à la fois : ce que l'on appelle fusion de pieuvres . Notez que la fusion d'octopus doit réussir sans conflits. Néanmoins, cela peut être utile.

HTH.