6 erreurs Git que vous ferez - et comment les corriger

Une des principales raisons pour lesquelles les développeurs utilisent un système de contrôle de code source comme Git est d'éviter les catastrophes. Si vous faites quelque chose d'aussi simple que de supprimer un fichier par erreur, ou si vous découvrez que les modifications que vous avez apportées à une douzaine de fichiers étaient toutes peu judicieuses, vous pouvez annuler ce que vous avez fait sans tracas.

Certaines erreurs Git sont plus intimidantes et difficiles à inverser, même pour les utilisateurs expérimentés de Git. Mais avec un peu de soin - et à condition de ne pas paniquer - vous pouvez revenir en arrière de certaines des pires catastrophes Git connues des programmeurs.

Voici une liste de plusieurs des plus gros boo-boos de Git, ainsi que des astuces pour les éliminer et en empêcher certains. Plus vous avancez dans la liste, plus les catastrophes s'aggravent.

Erreur Git n ° 1: vous avez oublié d'ajouter des modifications au dernier commit

C'est l'une des erreurs Git les plus faciles à résoudre. Disons que vous avez confié du travail à une branche locale, puis que vous vous êtes rendu compte que vous n'aviez pas organisé un certain nombre de fichiers nécessaires. Ou vous avez oublié d'ajouter certains détails dans le message de validation.

Sans peur. Premièrement, si vous avez de nouvelles modifications à mettre en œuvre, faites-le. Tapez ensuite git commit --amendpour modifier le message de validation. Une fois que vous avez terminé, appuyez sur Echap, puis tapez :xqpour enregistrer et quitter l'éditeur. (Cette dernière étape est celle qui dérange souvent les nouveaux venus de Git, qui ne se rendent pas toujours compte que l'éditeur Git intégré est vraiment son propre animal.)

Si vous ne faites que modifier des fichiers et que vous n'avez pas besoin de modifier le message de validation, vous pouvez utiliser git commit --amend --no-editpour ajouter les fichiers et ignorer le processus d'édition du message.

Une façon d'éviter ce genre d'erreur est de modifier la façon dont vous effectuez des commits dans Git. Si vous travaillez sur quelque chose où vous faites constamment de petits engagements pour suivre les révisions incrémentielles, faites-les dans une branche jetable. Pendant que vous faites cela, documentez les changements majeurs que vous apportez quelque part - n'attendez pas d'être confronté à la git commitligne de commande pour tout noter. Ensuite, lorsque vous atteignez un jalon majeur, utilisez git merge --squashdepuis votre branche jetable pour enregistrer les résultats dans la branche en cours de travail en tant que validation unique et propre, et utilisez les notes que vous avez prises pour le message de validation.

Erreur Git n ° 2: vous avez validé des modifications sur le maître (local)

Une autre gaffe courante: vous avez consciencieusement commis un tas de changements ... mais par erreur dans la branche principale de votre repo. Ce que vous vouliez vraiment faire était de les engager dans une nouvelle branche, ou dans cette devbranche que vous avez spécifiquement pour interrompre les changements.

Tout n'est pas perdu. Cette erreur peut être corrigée en trois commandes:

git branch new-branch

git reset HEAD ~ --hard

git checkout nouvelle-branche

La première commande crée la nouvelle branche avec laquelle nous voulons travailler. La deuxième commande réinitialise la branche principale juste avant le dernier commit, mais laisse les modifications que vous venez de faire dans la nouvelle branche. Enfin, nous passons à la nouvelle branche où vos modifications vous attendent.

Si vous avez effectué plusieurs validations, utilisez git reset HEAD~ --hard, où est le nombre de validations que vous souhaitez récupérer. Ou vous pouvez utiliser git reset , où est l'ID de hachage du commit cible si vous l'avez sous la main.

Pour éviter cette erreur, prenez l'habitude de créer de nouvelles branches et de passer à elles, même si elles vont simplement être supprimées, chaque fois que vous commencez une session avec votre code.

Erreur Git n ° 3: vous avez mis un fichier ou un répertoire dans la corbeille

Un autre désastre courant consiste à effacer par erreur le contenu d'un fichier ... et à ne le découvrir que beaucoup s'engagent dans la branche après coup . Heureusement, il existe une solution simple.

Tout d'abord, utilisez les git logoutils Git intégrés de votre IDE pour trouver l'ID de hachage d'un commit avant la modification du fichier. Ensuite, utilisez git checkout hash_id -- /path/to/filepour extraire uniquement ce fichier du commit en question. Notez que le chemin doit être relatif à la racine du projet. Cela placera la version antérieure du fichier dans la zone de préparation de votre projet.

Si vous voulez simplement revenir en arrière n commits, vous n'avez pas besoin de l'ID de hachage. Vous pouvez simplement émettre la commande git checkout HEAD~ -- /path/to/file, où est le nombre de validations que vous souhaitez retourner.

Si vous souhaitez extraire un répertoire entier de fichiers, utilisez le format générique de Git pour les chemins de fichiers. Par exemple, entrer  git checkout HEAD~1 -- ./src/**vous ramènera un commit et récupérera tout dans le /srcrépertoire à partir de la racine de votre projet.

Erreur Git # 4: Vous avez accidentellement supprimé une branche

Voici un scénario que nous redoutons tous: supprimer accidentellement une branche entière de notre référentiel. Celui-ci peut être soit très facile à récupérer, soit un peu plus délicat, selon les circonstances.

Tout d'abord, utilisez git reflogpour trouver le dernier commit effectué sur la branche. Ensuite, utilisez l'ID de hachage pour créer une nouvelle branche:

git checkout -b restored-branch

Notez que cela ne fera décoller votre bacon que si la branche en question a déjà été fusionnée. Si vous forcez la suppression d'une branche non fusionnée , vous avez un autre moyen de la trouver, à condition que vous n'ayez pas exécuté git gcsur le référentiel:

git fsck --full --no-reflogs --unreachable --lost-found

Cela videra une liste de tous les hachages de validation pour les objets qui ne sont plus accessibles, y compris les branches supprimées. Recherchez en bas de la liste une entrée «commit inaccessible», et essayez de restaurer cet ID de hachage dans une nouvelle branche pour voir si c'est celle que vous avez supprimée. Si ce n'est pas le cas, montez dans la liste jusqu'à la suivante et voyez ce que vous pouvez récupérer.

En règle générale, ne forcez jamais la suppression d'une branche par défaut, car vous pourriez facilement finir par gaspiller une branche non fusionnée qui contient encore quelque chose de précieux. Si vous supprimez habituellement des branches de force, c'est un signe que vos habitudes de travail avec les branches doivent être moins compliquées.

Erreur Git n ° 5: vous avez écrasé la branche distante avec git push

Une fois, je travaillais sur une copie locale d'un référentiel GitHub et j'ai poussé par erreur ma branche principale vers la copie distante avec l' --forceoption. J'ai fini avec une copie publique d'un repo qui n'était pas dans un état utilisable à l'époque. Gros oups.

Si vous avez fait une erreur comme celle-ci et que votre dépôt a été synchronisé avec le dépôt distant assez récemment, vous pouvez utiliser votre propre copie de la branche du dépôt distant pour le corriger. Basculez vers la branche dont vous avez besoin pour resynchroniser, en supposant que vous n'y êtes pas déjà, et exécutez cette commande:

git reset --hard /@{1}

Cela réinitialisera votre copie de à la dernière version synchronisée de . Dans mon cas, la branche était masteret le repo distant était origin, donc j'aurais pu utiliser git reset --hard origin/[email protected]{1}.

Utilisez ensuite git push -f pour restaurer le référentiel distant à son état antérieur.

Une façon d'éviter que cela ne se reproduise est d'interdire la poussée forcée. Vous pouvez configurer cela sur le référentiel Git distant avec cette commande:

git config --system receive.denyNonFastForwards true

Il peut arriver un moment où vous devez faire une poussée forcée, mais il est probablement préférable de l'activer lorsque vous en avez besoin et de l'éteindre lorsque vous n'en avez pas.

Erreur Git n ° 6: vous avez engagé des informations privées dans un dépôt public

C'est peut-être le problème Git le plus grave et le plus difficile à résoudre. Vous avez commis par erreur des données sensibles dans un référentiel public et vous souhaitez extraire chirurgicalement les fichiers du référentiel. Vous devez vous assurer que les données sensibles ne peuvent pas être trouvées même en revenant à un commit précédent, mais vous devez le faire  sans rien toucher d'autre.

C'est doublement difficile si le dossier en question a été commis, oh, il y a six semaines, et un camion d'autres travaux importants a été engagé entre-temps. Vous ne pouvez pas simplement revenir en arrière avant l'ajout du fichier; vous allez détruire tout le reste dans le processus.

La bonne nouvelle: quelques créateurs intrépides de Git ont créé un outil, le BFG Repo-Cleaner, spécialement dans le but de supprimer les mauvaises données des dépôts Git. BFG Repo-Cleaner vous permet d'effectuer rapidement des tâches courantes sur un dépôt, comme supprimer tous les fichiers correspondant à un caractère générique particulier ou contenant certains textes. Vous pouvez même transmettre un fichier qui répertorie tous les textes indésirables.

BFG Repo-Cleaner est essentiellement une automatisation pour un processus en plusieurs étapes utilisant git filter-branch. Si vous préférez faire les choses à la main, GitHub propose une présentation détaillée du processus. Mais l'outil BFG couvre la grande majorité des cas d'utilisation courants, dont beaucoup sont intégrés dans les options de ligne de commande de l'outil. De plus, le processus est long et complexe, et il est trop facile de se tirer une balle dans le pied quelque part en cours de route si vous le faites à la main.

Notez que si vous nettoyez les données d'une branche locale qui doit être synchronisée ailleurs, vous ne pourrez pas les synchroniser sauf par une poussée forcée vers les branches distantes. L'arbre de commit entier doit être réécrit, vous écrivez donc une histoire entièrement nouvelle à distance. Vous devrez également vous assurer que tout le monde extrait une nouvelle copie du dépôt réécrit après vos modifications, car leurs dépôts ne seront plus valides non plus.