Git: correction de bugs et correction de commits

Erreur de commit ... Comment y remédier? Un gâchis dans l'histoire des commits ... Comment rendre tout décent? L'auteur de l'article, dont nous publions la traduction aujourd'hui, dit qu'il a été écrit spécifiquement pour ceux qui ont posé de telles questions. Selon lui, après avoir étudié les techniques de travail avec Git présentées ici, vous pouvez considérablement progresser sur la voie de la maîtrise de Git.


Il est supposé que le lecteur de cet article connaît déjà les bases de Git. Si ce n'est pas le cas, il est d'abord recommandé de maîtriser la base, par exemple, en utilisant ce matériau.

Correction de bugs dans les commits

Ici, nous allons examiner plusieurs scénarios d'erreurs dans les commits et leur correction.

▍ Scénario numéro 1

Supposons que vous ayez validé de nombreux fichiers et réalisé que le message de validation n'était pas très clair. Après cela, vous avez décidé de modifier ce message. Pour ce faire, utilisez la git commit --amend . Voici un exemple de son application:

 git commit --amend -m "New commit message" 

▍ Scénario numéro 2

Supposons que vous vouliez valider six fichiers, mais que vous n'en avez commis que cinq par erreur. Il semble que vous pouvez corriger cette erreur simplement en créant un nouveau commit et en y ajoutant le sixième fichier manquant.

Cette approche a droit à la vie. Mais afin de conserver l'historique des validations en bon état, il serait probablement préférable de pouvoir ajouter un fichier ignoré au même commit. Cela peut être fait, encore une fois, avec la git commit --amend . Son utilisation ressemble à ceci:

 git add file6 git commit --amend --no-edit 

L'indicateur --no-edit signifie que le message de validation ne change pas.

▍ Scénario numéro 3

Les commits effectués dans Git sont liés au nom de l'auteur et à son adresse e-mail. En règle générale, ces données sont indiquées en effectuant la configuration initiale de Git. En conséquence, ceux qui utilisent Git peuvent ne pas, lors de l'exécution de chaque commit, se soucier des informations sur son auteur.

De plus, il est tout à fait possible que lorsque vous travaillez avec certains projets, vous devrez utiliser des informations sur l'auteur, par exemple, une adresse e-mail différente des principales. Pour un tel projet, vous devez spécifier une adresse e-mail à l'aide de cette commande:

 git config user.email "your email id" 

Supposons que vous ayez oublié de faire cette configuration et que vous ayez déjà effectué le premier commit. Corriger la situation peut déjà nous être familier. En l'utilisant, vous pouvez modifier les informations sur l'auteur du commit précédent:

 git commit --amend --author "Author Name <Author Email>" 

▍ Remarque

Utilisez la commande amend uniquement dans votre référentiel local. Son utilisation dans des référentiels distants peut entraîner une énorme confusion.

Mettre de l'ordre dans l'histoire des commits

Supposons que vous travaillez sur un morceau de code pour un projet. Vous savez que cela prendra environ dix jours. Pendant ces dix jours, d'autres développeurs s'engagent dans le référentiel source.

Il est recommandé de maintenir la synchronisation entre les référentiels local et distant. Cela évite les nombreux conflits de fusion qui surviennent lorsque les référentiels sont trop rares pour être synchronisés. En suivant cette pratique, vous décidez de télécharger les modifications à partir du référentiel distant tous les deux jours.

Chaque fois que vous téléchargez du code depuis une télécommande vers le référentiel local, un nouveau commit de fusion est créé dans le référentiel local. Cela signifie que dans votre historique de validation local, il y aura de nombreuses validations de ce type qui peuvent confondre celui qui affichera votre code.


Historique des validations dans le référentiel local

Comment ranger l'historique des commits? Pour résoudre ce problème, vous pouvez utiliser la git rebase .

Commande itGit rebase

Considérez la git rebase comme exemple.


Valide dans la branche Release et dans la branche Feature

Il existe trois Rcommit1 dans la branche Release : Rcommit1 , Rcommit2 et Rcommit3 . Vous avez créé votre branche Feature partir de la branche Release alors qu'elle n'avait qu'un seul commit - Rcommit1 . Après cela, vous avez ajouté deux validations à la branche Feature . Ce sont Fcommit1 et Fcommit2 . Votre objectif est de télécharger des validations de la branche Release vers votre branche Feature . Pour ce faire, vous allez utiliser la commande rebase .

Nous utiliserons la release et la feature noms pour les deux branches considérées.

Par conséquent, l'utilisation de la rebase ressemblera à ceci:

 git checkout feature git rebase release 

▍ Caractéristiques de la commande rebase

La commande rebase utilisée pour garantir que la branche Feature a du nouveau code de la branche Release .

Lors de l'application de cette commande, le système essaie d'ajouter chaque validation à la branche Feature , une à la fois, et vérifie les conflits. Si cela semble compliqué, regardons la figure suivante. Cela montre les mécanismes internes de la rebase .


Branche de fonctionnalités et trois étapes de la commande rebase

Étape 1

Lorsque la commande est appelée, la branche Feature pointe vers la tête de la branche Release . Après cela, il y a trois Rcommit1 dans la branche Feature : Rcommit1 , Rcommit2 et Rcommit3 . Vous aurez peut-être ici une question sur ce qui s'est passé avec les Fcommit1 et Fcommit2 . Ces commits n'ont pas disparu, ils seront utilisés dans les prochaines étapes.

Étape 2

Git essaie maintenant d'ajouter le commit Fcommit1 à la branche Feature . S'il n'y a pas de conflit, Fcommit1 ajouté après Rcommit3 . Si un conflit est détecté, Git le signalera et vous devrez résoudre ce conflit manuellement.

Étape 3

Une fois le commit Fcommit1 ajouté à la branche Feature , Git essaie également d'y ajouter Fcommit2 . Là encore, s'il n'y a pas de conflits, Fcommit2 ajouté après Fcommit1 et l'opération s'est terminée avec succès. Si un conflit est détecté, Git, comme précédemment, le signalera et proposera de le résoudre.

Une fois la commande rebase vous pouvez voir qu'il existe des Rcommit1 , Rcommit2 , Rcommit3 , Fcommit1 et Fcommit2 dans la branche Feature .

▍ Remarque

Lorsque vous travaillez avec Git, la commande de merge et la commande de rebase sont rebase . Cela ne veut pas dire que l'un d'eux est préférable à l'autre.

Si vous utilisez la commande merge , vous recevrez un commit de merge . Si vous utilisez rebase , vous n'aurez pas de rebase supplémentaires.

Il est recommandé d'utiliser ces commandes dans diverses situations. Ainsi, rebase convient à la mise à jour du code du référentiel local basé sur le dernier code du référentiel distant. Utilisez la commande de merge pour effectuer des demandes d'extraction pour fusionner la branche Feature avec la branche Release ou Master .

Résumé

Après avoir étudié les concepts présentés dans cet article, vous avez amélioré vos compétences Git et êtes plus proche du niveau d'un expert Git. Nous espérons que ce que vous avez appris ici vous sera utile. Mais le monde de Git est immense, donc, ayant maîtrisé quelque chose de nouveau, ne vous arrêtez pas là et passez à autre chose.

Chers lecteurs! Avez-vous rencontré un gâchis dans git commits?