J'essayais de modifier un ancien message de validation comme expliqué ici .
Le truc, c'est que maintenant, quand j'essaye de courir, rebase -i HEAD~5ça dit interactive rebase already started.
Alors j'essaye: git rebase --continuemais j'ai cette erreur:
error: Ref refs/heads/master is at 7c1645b447a8ea86ee143dd08400710c419b945b but expected c7577b53d05c91026b9906b6d29c1cf44117d6ba
fatal: Cannot lock the ref 'refs/heads/master'.
Des idées?
Réponses:
Ça dit:
Lorsque vous enregistrez et quittez l'éditeur, il vous ramènera à ce dernier commit dans cette liste et vous déposera sur la ligne de commande avec le message suivant:
$ git rebase -i HEAD~3
Stopped at 7482e0d... updated the gemspec to hopefully work better
You can amend the commit now, with
Cela ne signifie pas:
tapez à nouveau
git rebase -i HEAD~3
Essayez de ne pas taper git rebase -i HEAD~3lorsque vous quittez l'éditeur, et cela devrait fonctionner correctement.
(sinon, dans votre situation particulière, un git rebase -i --abortpeut être nécessaire pour tout réinitialiser et vous permettre de réessayer)
Comme Dave Vogt le mentionne dans les commentaires, il git rebase --continues'agit de passer à la tâche suivante du processus de rebasage, après avoir modifié le premier commit .
De plus, Gregg Lind mentionne dans sa réponse la rewordcommande degit rebase :
En remplaçant la commande "pick" par la commande "edit", vous pouvez dire
git rebased'arrêter après avoir appliqué ce commit, afin que vous puissiez éditer les fichiers et / ou le message de commit, modifier le commit et continuer le rebasage.Si vous voulez juste éditer le message de commit pour un commit, remplacez la commande "
pick" par la commande "reword" , depuis Git1.6.6 (janvier 2010) .Il fait la même chose '
edit' lors d'un rebase interactif, sauf qu'il vous permet uniquement d'éditer le message de validation sans rendre le contrôle au shell . Ceci est extrêmement utile.
Actuellement, si vous souhaitez nettoyer vos messages de validation, vous devez:
$ git rebase -i next
Ensuite, définissez tous les commits sur «modifier». Puis sur chacun:
# Change the message in your editor.
$ git commit --amend
$ git rebase --continue
Utiliser «
reword» au lieu de «edit» vous permet de sauter les appelsgit-commitetgit-rebase.
Comme l'a suggéré Gregg Lind, vous pouvez utiliser des reformulations pour être invité à ne modifier que le message de validation (et laisser le commit intact dans le cas contraire):
git rebase -i HEAD~n
Voici nla liste des n derniers commits.
Par exemple, si vous utilisez git rebase -i HEAD~4, vous pouvez voir quelque chose comme ceci:
pick e459d80 Do xyz
pick 0459045 Do something
pick 90fdeab Do something else
pick facecaf Do abc
Maintenant, remplacez pick par reword pour les commits dont vous souhaitez modifier les messages:
pick e459d80 Do xyz
reword 0459045 Do something
reword 90fdeab Do something else
pick facecaf Do abc
Quittez l'éditeur après avoir enregistré le fichier, et ensuite vous serez invité à modifier les messages pour les commits que vous avez marqués de reformulation , dans un fichier par message. Notez qu'il aurait été beaucoup plus simple de simplement modifier les messages de validation lorsque vous les avez remplacés pickpar reword, mais cela n'a aucun effet.
En savoir plus sur la page de GitHub pour modifier un message de validation .
FWIW, git rebase interactive a maintenant une option "reword", ce qui rend cela beaucoup moins pénible!
reword, pourquoi git ne vous permet-il pas simplement d'éditer les messages de validation dans ce fichier avec la liste des validations? Au lieu de cela, il lancera l'éditeur avec un fichier de message de validation par rewordligne. C'est tout simplement inutile. Même si d'autres actions que pickou rewordnécessitent le lancement de commandes externes, rewordcela ne le nécessiterait pas.
Je voulais juste fournir une option différente pour cela. Dans mon cas, je travaille généralement sur mes succursales individuelles, puis je fusionne pour devenir maître, et les engagements individuels que je fais à ma section locale ne sont pas si importants.
En raison d'un hook git qui vérifie le numéro de ticket approprié sur Jira mais qui était sensible à la casse, j'ai été empêché de pousser mon code. De plus, le commit a été fait il y a longtemps et je ne voulais pas compter combien de commits pour revenir sur le rebase.
Donc, ce que j'ai fait a été de créer une nouvelle branche à partir du dernier master et d'écraser tous les commits de la branche problématique en un seul commit sur la nouvelle branche. C'était plus facile pour moi et je pense que c'est une bonne idée de l'avoir ici comme référence future.
Du dernier maître:
git checkout -b new-branch
ensuite
git merge --squash problem-branch
git commit -m "new message"
rebase -ipendant environ 2 heures et sans succès. Mon commit était derrière 18 commits, donc vous pouvez l'imaginer. C'était le moyen le plus simple et pratique que je pouvais trouver sans avoir besoin d'utiliser le rebase. Merci mon ami!
Voici un très joli Gist qui couvre tous les cas possibles: https://gist.github.com/nepsilon/156387acf9e1e72d48fa35c4fabef0b4
Aperçu:
git rebase -i HEAD~X
# X is the number of commits to go back
# Move to the line of your commit, change pick into edit,
# then change your commit message:
git commit --amend
# Finish the rebase with:
git rebase --continue
git rebase --continueà la tâche suivante du processus de rebasage, après avoir modifié le premier commit.