La meilleure solution consiste simplement à garder les commits linéaires en premier lieu. Si vous voulez utiliser deux branches marchant sur cette ligne de commits, cela a du sens; mais en ayant deux lignes de commits, vous créez un travail inutile. A partir des commentaires, je déduis que vous avez quelques changements de configuration de base, affectant les répertoires de sortie et autres. La gestion de ces configurations dans le code de sorte que vous deviez conserver un changement de code pour rediriger la sortie est une erreur de conception, et le problème que vous rencontrez ici est un symptôme. Vous obtiendrez plus pour votre argent en résolvant ce problème. Ensuite, vous pouvez simplement démarrer les deux branches dans le même commit, faire les changements et les valider dans la branche test, lancer votre test; si elle réussit, fusionnez (en utilisant l'avance rapide) la modification dans la branche principale et, si ce n'est pas le cas, retournez la branche de test. Mais si vous êtes décidé à dépenser un effort ponctuel à la place (et que vous avez toujours cette faille de conception qui vous attendra la prochaine fois que vous voulez faire quelque chose), alors vous pouvez plutôt faire ce que vous faites, puis choisissez la validation HEAD de la branche de test sur la branche principale.
https://git-scm.com/docs/git-cherry-pick
Notez que au moins 9 fois sur 10, si je mentionne picorage il est d'appeler le plus en commande git sur recommandé. Les opérations liées les plus proches (que je préfère quand elles sont applicables) sont la fusion par rebase et la fusion de squash; mais ni l'un ni l'autre ne fonctionne comme vous le voudriez dans ce cas. Pour moi, c'est une preuve supplémentaire que la conception n'est pas juste pour commencer.
Pourquoi utiliser des branches? Commit chaque fois et 'git diff HEAD^... HEAD'. – Ryan
Ils stockent les résultats et se connectent dans des répertoires différents pour faciliter la comparaison – Gabriel