L'erreur:
J'ai git rebase -i --root
édité ma branche, pensant par ignorance que je pouvais reformuler le premier commit différant du master (la vue par défaut de GitHub pour Windows est la comparaison avec master, cachant son intégralité).
J'ai fait pousser une barbe dans la Silicon Valley pendant que 900+ commits se chargeaient dans Sublime. Sortant sans changement, j'ai chargé ma batterie, puis j'ai procédé au rasage, car tous les 900+ engagements individuels ont été rebasés de manière nonchalante - réinitialisant leurs temps de validation jusqu'à maintenant.
Déterminé à battre Git et à conserver les temps d'origine, j'ai supprimé ce référentiel local et re-cloné depuis la télécommande.
Maintenant, il avait rajouté un dernier commit inutile à master que je souhaitais supprimer, alors j'ai procédé comme ça.
Épuiser les options:
Je ne voulais pas git revert
- cela créerait un commit supplémentaire, donnant à Git le dessus.
git reset --hard HEAD
n'a rien fait, après avoir vérifié le reflog
, le dernier et le seul HEAD
était le clone - Git gagne.
Pour obtenir le SHA le plus récent, j'ai vérifié le référentiel distant sur github.com - gain mineur.
Après avoir réfléchi git reset --hard <SHA>
, j'ai mis à jour une autre branche pour maîtriser et 1 ... 2 ... pouf! le commit était de retour - Git gagne.
Revenir au maître, le temps d'essayer git rebase -i <SHA>
, puis supprimer la ligne ... en vain, triste à dire. " Si vous supprimez une ligne ici CE COMMIT SERA PERDU ". Ah ... passé sous silence la nouvelle fonctionnalité troll le n00b dans les notes de version 2.8.3 .
La solution:
git rebase -i <SHA>
alors d, drop = remove commit
.
Pour vérifier, j'ai vérifié dans une autre branche, et le tour est joué - pas de cachette de validation pour récupérer / tirer du maître.
https://twitter.com/holman/status/706006896273063936
Bonne journée.
cherry-pick
etdelete
un seul commit qui a eu lieu il y a quelque temps.