Branche principale distante contaminée ou Anti-Cherry-Pick

Question

Je suis dans une situation où le référentiel distant a des "mauvais" validations. par exemple.

... o ---- C ---- A ---- B origin/master 

Où A est mauvais (mais B est bon) Je veux la télécommande pour devenir ...

... o ---- C ---- B origin/master 
        \ 
        A origin/dev 

Il n'est pas évident pour moi comment faire cela.

Dans le cas où une rebase est inappropriée, un résultat différent est nécessaire. Il en résulte une branche de développement contenant la validation A et le maître ne contenant pas la validation A. La question révisée est: Comment faire un anti-cerise? Ainsi, plutôt que de générer un correctif qui modifie le référentiel de l'état C vers A, appliquez un correctif qui change B en A.

Answer 1

Tirez de sorte que vous ayez le même référentiel localement.

utilisation git rebase --interactive (voir this rundown si vous n'êtes pas familier avec rebasage interactif) pour réordonner A et B engage, de sorte que vous avez maintenant

... o ---- o ---- B ---- A master 

Commander une nouvelle branche dev à partir de cet endroit, de sorte que vous obtenez

... o ---- o ---- B ---- A master, dev 

Basculez vers la branche principale, effectuez un git reset --hard HEAD^ pour rembobiner cette branche de validation. Vous avez maintenant

... o ---- o ---- B master 
        \ 
        A dev 

maintenant git push --force --all et vous devriez être doré. (Vous avez besoin de --force car vous réécrivez l'historique dans le référentiel distant, ce qui est dangereux et déconseillé si d'autres développeurs l'ont déjà retiré.)