J'ai commis une modification et j'ai oublié d'ajouter un fichier à l'ensemble de modifications. Après d'autres commits, j'ai réalisé que le fichier était maintenant absent d'un HEAD^4commit.
Comment réécrire un commit précédent pour inclure le fichier manquant?
Réponses:
Utilisez git rebase --interactive HEAD~4et définissez l' editoption pour le commit que vous souhaitez modifier.
N'oubliez pas que vous ne devez pas modifier les validations transmises au référentiel distant de cette façon. Il est préférable d'ajouter un nouveau commit avec un fichier manquant dans ce cas.
git push -fsi je suis sûr que l'amont n'a pas changé?
add-ed les fichiers manquants, donc j'ai fait un commit avec "xxx" comme message. Ensuite, j'ai fait la commande rebase et j'ai changé le commit "xxx" de "pick" à "edit". Ensuite, j'ai fait "git rebase --continue". Maintenant, quand je regarde l'historique, j'ai "xxx" comme dernier commit, et le commit précédent auquel je voulais les ajouter est inchangé! Je me demande où était mon erreur?
Je me rends compte que les gens peuvent google et venir ici pour trouver une réponse plus simple: et si c'était juste le dernier commit? (La question d'OP est de réparer le 4ème commit dans l'histoire)
Dans le cas où vous vous engagez et réalisez que vous avez oublié d'ajouter un fichier immédiatement , faites simplement:
# edited file-that-i-remember.txt
git add file-that-i-remember.txt
git commit
# realize you forgot a file
git add file-that-i-forgot.txt
git commit --amend --no-edit
Où --no-editconservera le même message de validation.
Peasy facile!
--amendont des hachages différents
HEAD^4. C'est ok comme ça, juste comme un addendum pour référence. ;)
Si vous n'avez PAS poussé ces 4 commits, vous pouvez le faire comme suit:
Créez des fichiers de correctifs pour tous ces commits:
git format-patch -4
Rewind back de 4 commits:
git reset --hard HEAD~4
Ajouter un fichier manquant:
git add missing-file
Engagez-le avec --amend:
git commit --amend
Réappliquez tous les correctifs enregistrés:
git am *.patch
Si vous avez poussé, vous ne devez PAS utiliser cette méthode. Au lieu de cela, admettez simplement votre erreur et créez un autre commit au-dessus de HEAD qui résout ce problème.
git format-patch/ git ambeaucoup mieux. Plus important encore, cela vous donne plus de confiance si vous gâchez quelque chose - le commit enregistré sous forme de patch dans un fichier physique est votre meilleur filet de sécurité.
git gc
rm *.patch)
Bien que la réponse acceptée soit correcte, il manque des instructions détaillées sur la façon de modifier un commit pendant un processus de rebase.
Commencez par lancer un processus de rebase:
git rebase --interactive HEAD~4
Une liste des commits sera présenté, choisissez un commettras vous voulez modifier en changeant le mot pickpour editet enregistrez le fichier.
Apportez les modifications nécessaires à votre code (n'oubliez pas d'appeler git addpour les nouveaux fichiers)
Une fois toutes les modifications effectuées, émettez git commit --amend- cela modifiera un commit marqué commeedit
Appelez git rebase --continuequi terminera le processus (s'il y a plus de commits marqués comme edit, les étapes ci-dessus doivent être répétées)
Notes IMPORTANTES:
NE supprimez PAS les lignes marquées comme pickque vous ne souhaitez pas modifier - laissez-les telles quelles. La suppression de ces lignes entraînera la suppression des validations associées
GIT vous y oblige stashavant de rebaser si votre répertoire de travail n'est pas propre; vous pouvez cependant git stash pop / git stash applylors du rebase, afin de modifier ces changements (c'est-à-dire les changements cachés avant de démarrer le processus de rebase) en un commit marqué commeedit
si quelque chose s'est mal passé et que vous souhaitez annuler les modifications apportées pendant le processus de rebase avant qu'il ne soit terminé (c'est-à-dire que vous voulez revenir au point avant de commencer le rebase), utilisez git rebase --abort- lisez également: Comment annuler un rebase interactif si --abort ne le fait pas ' t travailler?
Comme indiqué dans la réponse acceptée:
N'oubliez pas que vous ne devez pas modifier les validations transmises au référentiel distant de cette façon. Il est préférable d'ajouter un nouveau commit avec un fichier manquant dans ce cas.
La réponse se trouve dans le Git Book (paragraphe intitulé " The Perils of Rebasing "):
Ne rebasez pas les commits qui existent en dehors de votre référentiel.
Si vous suivez cette directive, tout ira bien. Sinon, les gens vous détesteront et vous serez méprisé par vos amis et votre famille.
Lorsque vous rebasez des éléments, vous abandonnez les commits existants et en créez de nouveaux qui sont similaires mais différents. Si vous poussez des commits quelque part et que d'autres les tirent vers le bas et basent le travail sur eux, puis vous réécrivez ces commits avec git rebase et les poussez à nouveau, vos collaborateurs devront re-fusionner leur travail et les choses deviendront désordonnées lorsque vous essayez de ramenez leur travail dans le vôtre.
[...]