Remarque perev. : Il y a quelques jours, une petite mais très utile note est apparue dans le blog pour les ingénieurs de notre projet GitLab préféré avec des instructions qui aident à gagner du temps et des nerfs en cas de divers problèmes qui surviennent lorsque vous travaillez avec Git. Il est peu probable qu'ils soient nouveaux pour les utilisateurs expérimentés, mais il y aura certainement ceux à qui ils seront utiles. Et à la fin de ce document, nous avons ajouté un petit bonus de nous-mêmes. Passez un bon vendredi!Nous commettons tous des erreurs, en particulier lorsque nous travaillons avec des systèmes complexes comme Git. Mais souvenez-vous: Git arrive!
Si vous débutez avec Git, apprenez les
bases de son utilisation sur la ligne de commande. Et ici, je vais vous expliquer comment vous pouvez corriger les six erreurs les plus courantes dans Git.
1. Oups ... je me suis trompé dans le message au dernier commit
Après plusieurs heures de codage, il est facile de se tromper dans le message de validation. Heureusement, cela est facile à résoudre:
git commit --amend
Avec cette commande, un éditeur de texte s'ouvrira et vous permettra d'apporter des modifications au message au dernier commit. Et personne ne saura que vous avez écrit «ajouté» avec trois «d».
2. Oups ... J'ai oublié d'ajouter le fichier au dernier commit
Un autre bogue populaire dans Git est un commit trop hâtif. Avez-vous oublié d'ajouter le fichier, oublié de l'enregistrer ou devez-vous apporter une petite modification pour que le commit soit significatif? Votre ami sera à nouveau
--amend .
Ajoutez le fichier manquant et exécutez cette commande correcte:
git add missed-file.txt git commit --amend
Vous pouvez maintenant soit corriger le message, soit simplement l'enregistrer dans sa forme d'origine (avec le fichier ajouté).
3. Oups ... J'ai ajouté un fichier qui ne devrait pas se trouver dans ce référentiel
Mais que faire si vous avez la situation inverse? Que faire si vous avez ajouté un fichier que vous ne souhaitez pas valider? Un fichier ENV trompeur, un répertoire de construction ou une photo avec un chat qui a été accidentellement enregistré dans le mauvais répertoire ... Tout est résolu.
Si vous n'avez fait que l'
étape du fichier et que vous ne l'avez pas encore engagé, tout se fait par une simple
réinitialisation du fichier souhaité (situé dans l'étape):
git reset /assets/img/misty-and-pepper.jpg
Si vous validez toujours la modification, une étape préliminaire supplémentaire est requise:
git reset --soft HEAD~1 git reset /assets/img/misty-and-pepper.jpg rm /assets/img/misty-and-pepper.jpg git commit
La validation sera annulée, l'image sera supprimée, puis une nouvelle validation sera effectuée.
Remarque perev. : Comme indiqué dans les commentaires sur l'article d'origine, ce problème peut également être résolu en utilisant le --amend déjà mentionné. Apparemment, avec ce paragraphe, l'auteur a voulu montrer ce qu'il y avait d'autre pour changer l'historique des commits pour corriger l'erreur.4. Oups ... J'ai commis des modifications au maître
Donc, vous travaillez sur une nouvelle fonctionnalité et vous êtes pressé, oubliant de créer une nouvelle branche pour elle. Vous avez déjà validé un tas de fichiers et toutes ces validations sont dans le maître. Heureusement, GitLab
peut empêcher push'y directement dans master. Par conséquent, nous pouvons annuler toutes les modifications nécessaires dans une nouvelle branche avec les trois commandes suivantes:
Remarque : assurez-vous de valider ou de cacher les zéros en premier, vos modifications - sinon elles seront toutes perdues! git branch future-brunch git reset HEAD~ --hard git checkout future-brunch
Une nouvelle branche sera créée, en master - une restauration est effectuée à l'état dans lequel elle se trouvait avant vos modifications, puis une
extraction de la nouvelle branche est effectuée avec toutes vos modifications.
5. Oups ... J'ai fait une erreur au nom de la succursale
Les plus attentifs ont pu remarquer dans l'exemple précédent une erreur dans le nom de la branche. Il est presque 15 heures et je n'ai toujours pas dîné, donc ma faim a appelé la nouvelle branche (
br a nch ) comme
future-br u nch . Goodies!
Renommez cette branche de la même manière que lorsque vous renommez un fichier à l'aide de la commande
mv , c'est-à-dire en le plaçant dans un nouvel emplacement avec le nom correct:
git branch -m future-brunch feature-branch
Si vous poussez déjà cette branche, vous aurez besoin de quelques étapes supplémentaires. Nous allons supprimer l'ancienne branche de la
télécommande et pousser la nouvelle:
git push origin --delete future-brunch git push origin feature-branch
Remarque perev. : Vous pouvez toujours supprimer une branche de la télécommande à l'aide de: git push origin :future-brunch
6. Oups ... je l'ai encore fait!
La dernière commande en cas de problème. Lorsque vous avez accumulé et poussé un tas de solutions avec Stack Overflow, après quoi tout dans le référentiel est devenu encore pire qu'au début. Nous avons tous fait face à une situation similaire ...
git reflog affiche une liste de toutes les opérations que vous avez effectuées. Ensuite, il vous permet d'utiliser les capacités de voyage dans le temps magiques de Git, c'est-à-dire revenir à n'importe quel moment du passé. Je dois noter que c'est votre dernier espoir - vous ne devriez pas y recourir dans des cas simples. Donc, pour obtenir la liste, faites:
git reflog
Chacune de nos étapes est sous l'œil vigilant de Git. La gestion de l'équipe sur le projet ci-dessus a produit les éléments suivants:
3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/future-brunch to refs/heads/feature-branch 3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to future-brunch 2b7e508 (master) HEAD@{3}: reset: moving to HEAD~ 3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo 2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1 37a632d HEAD@{6}: commit: Adds the client logo to the project 2b7e508 (master) HEAD@{7}: reset: moving to HEAD 2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site dfa27a2 HEAD@{9}: reset: moving to HEAD dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site 700d0b5 HEAD@{11}: commit: Addded contributing info to the site efba795 HEAD@{12}: commit (initial): Initial commit
Faites attention à la colonne la plus à gauche - c'est l'indice. Si vous souhaitez revenir à n'importe quel point de l'historique, exécutez la commande suivante, en remplaçant
{index} par la valeur appropriée (par exemple,
dfa27a2 ):
git reset HEAD@{index}
Donc, maintenant, vous avez six façons de sortir des Gitfalls les plus fréquents
(jeu de mots: piège se traduit par «piège, erreur» - environ Transl. ) .
Bonus du traducteur
Tout d'abord, un précieux commentaire sur tout ce qui est écrit ci-dessus (à l'exception du paragraphe 5). Gardez à l'esprit que ces actions modifient l'historique des validations, elles ne doivent donc être effectuées que si les modifications n'ont pas été envoyées à
distance (push'nut). Sinon, l'ancien mauvais commit sera déjà sur la branche
distante et vous devrez soit effectuer
git pull (ce que la
fusion fera, puis essayer de «vider» l'historique entraînera de pires conséquences), ou
git push --force , qui est lourd de perte de données lorsque vous travaillez avec une branche de plusieurs personnes ...
Maintenant - petits ajouts utiles de notre expérience:
- Si vous (accidentellement ou non) avez changé de branche et que vous devez revenir à la précédente, le moyen le plus rapide est d'utiliser
git checkout - . - Si vous avez accidentellement ajouté un fichier au commit qui ne devrait pas y être ajouté, mais que vous ne l'avez pas encore fait, utilisez
git reset HEAD path/to/file . Une situation similaire est décrite au paragraphe 3, mais en réalité elle est plus large, car fait référence à toute modification inutile de la validation (pas seulement le cas d'un fichier supplémentaire). - Il est recommandé de ne pas trop commettre, en utilisant l'option
-p lors de l'ajout d'un fichier à une validation ( git add -p ). Cela vous permet de revoir chaque modification apportée au commit. Mais il convient de se rappeler qu'il n'ajoute pas de fichiers non suivis au commit - ils doivent être ajoutés sans ce paramètre. - Un certain nombre de bonnes recommandations (y compris des recommandations plus complexes) peuvent être trouvées dans l'article de 2014 « Tutoriel Git: 10 problèmes Git courants et comment les résoudre ». Notez en particulier l'utilisation de
git revert et git rebase -i .
PS du traducteur
Lisez aussi dans notre blog: