Avec le boom de technologie, il devient inévitable pour tout informaticien de travailler simultanément sur plusieurs données et vos données évoluent constamment avec le temps. Il est également essentiel de suivre chaque modification des données et d'être prêt à annuler ou à annuler tout changement indésirable si nécessaire.
Je dois avouer que le versionnage de mes données dans Git me permet d'être plus expérimental dans le développement de mon projet. Si je me trompe, je sais que git a toujours un moyen d'annuler et / ou de rétablir cette version de mon projet telle qu'elle était avant que je me trompe. Chaque La couche est conçue pour permettre aux changements de données d'être examinés et modifiés et / ou corrigés avant de déplacer les données à l'étape suivante. Voici donc les erreurs qui sont couvertes dans ce blog:
- Supprimer les fichiers / répertoires de l'index
- Modifier le dernier message validé
- J'ai oublié certains changements lors du dernier commit
- Ignorer les modifications locales
- Données personnelles validées dans le référentiel local
- Remplacement du dernier commit par un nouveau commit
- A commis les mauvaises données
- Revenir à mon ancien état de projet
- Récupérer une branche locale supprimée
- Annuler les modifications effectuées dans un commit
- A donné un mauvais nom à ma succursale
- Vous souhaitez réorganiser les journaux d'historique avant de passer à la télécommande
- Validation des modifications non liées en un seul commit
- Modifier l'email de l'auteur dans tous les commits sur toutes les branches
- Fichiers perdus et trouvés
- J'ai oublié quelle branche a mon commit-id
- Supprimer un commit de l'historique
- Poussé une mauvaise branche vers la télécommande
Supprimer les fichiers / répertoires de l'index
Lors de l’ajout et / ou de la modification de fichiers, vous avez souvent tendance à utiliser le comportement par défaut de la commande «git add», qui consiste à ajouter tous les fichiers et répertoires à l’index.Vous ressentez souvent le besoin d'annuler la mise en scène de certains fichiers ou de les modifier une dernière fois avant de les valider.
c ++ fait le tri
Syntaxe: git reset
Le retrait des fichiers intermédiaires de la zone Index vous donne une autre chance de retravailler vos données avant de vous engager dans un dépôt local.
Modifier le dernier message validé
Commander: git commit --amend
Vous pouvez modifier le dernier message de validation sans en créer un nouveau. Pour répertorier les journaux de validation, j'ai défini un alias «hist»:
Commander: git config --global alias.hist 'log --pretty = format: '% C (jaune)% h% Creset% ad | % C (vert)% s% Creset% C (rouge)% d% Creset% C (bleu) [% an] '--graph --decorate --date = short'x
Ne modifiez pas le message de validation qui est déjà poussé vers un référentiel distant et partagé avec d'autres, car cela rendrait l'historique de validation antérieur invalide et donc tout travail basé sur celui-ci pourrait être affecté.
J'ai oublié certains changements lors du dernier commit
Supposons que vous ayez oublié d’apporter des modifications et que vous ayez déjà validé votre instantané. Vous ne voulez pas non plus faire un autre commit pour mettre en évidence votre erreur.
Commander: git commit --amend
J'ai mis en évidence la manière dont l'identifiant sha-1 de l'objet de validation récent a été recréé et modifié. J'ai fait semblant d'avoir fait un seul commit mélangeant les deux changements en un seul.
Ignorer les modifications locales
Donc, voici un cas où j'ai modifié le fichier «README» et l'ai mis en scène. Ensuite, j'ai modifié le même fichier une deuxième fois mais j'ai réalisé que je ne voulais pas du deuxième changement.
Maintenant, permettez-moi de ne pas annuler la totalité du changement manuellement, je peux simplement extraire la version intermédiaire du fichier.
Syntaxe:
git checkout -–Modifications locales dans un fichier
git checkout -–Modifications locales dans tous les fichiers du répertoire & timide & timide
Commander: git checkout - README
J'ai donc abandonné mes dernières modifications apportées au fichier et accepté la version intermédiaire du fichier. Dans le prochain commit, seule la version intermédiaire du fichier va dans le référentiel local.
Données personnelles validées dans le référentiel local
Je souhaite supprimer certaines données du référentiel local mais conserver les fichiers dans le répertoire de travail.
Syntaxe:
git reset - HEAD mixte ~
git reset --mixed
Commander: git reset - HEAD mixte ~ 1
HEAD ~ 1 indique un commit juste avant le commit récent pointé par la branche actuelle HEAD.
Les fichiers de l'instantané actuel ont été supprimés à la fois du référentiel local et de la zone de transit. Ajoutez les modèles suivants dans le fichier global .gitignore pour les exclure du suivi par git.
vim ~ / .gitignore_global
# fichiers de mot de passe #
*.passer
*.clé
* .passwd
Avec cela, le commit qui contenait l'instantané des fichiers de mots de passe est supprimé et vous obtenez une zone de transit propre. Mes fichiers sont toujours présents sur mon répertoire de travail mais ne sont plus présents dans le référentiel local, ne seront pas non plus poussés sur un référentiel distant.
Mise en garde: Si vous les perdez, git ne peut pas les récupérer pour vous car il ne le sait pas.
Remplacez le dernier commit par un nouveau commit
Syntaxe: git reset --soft [/ HEAD ~ n>]
L’option «–soft» supprime simplement les fichiers validés du référentiel local pendant qu’ils sont encore en attente dans l’index et vous pouvez les valider à nouveau après un examen. est le sha-1 de l'instantané que vous souhaitez supprimer du référentiel local. où n est le nombre de validations avant la validation HEAD
Commander :git reset --soft HEAD ~ 1
Modifiez les fichiers et mettez-les à nouveau en scène
Commander: git commit -m 'Ajout d'index.html et de style.css'
Votre historique de validation s'avère maintenant:
A commis les mauvaises données
Syntaxe:
git reset --hard HEAD ~ n–Réinitialiser le projet à «n» commits avant le dernier instantané validé
git reset --hard–Réinitialiser le projet sur l'instantané de l'ID de validation donné
Commander: git reset --hard HEAD ~ 1
Le dernier commit et les fichiers corrompus sont supprimés du référentiel local, de la zone de préparation ainsi que du répertoire de travail.
Mise en garde: C'est une commande dangereuse car vous finissez par perdre des fichiers dans le répertoire de travail. Non recommandé sur un référentiel partagé à distance.
Revenir à mon ancien état de projet
Vous pouvez revenir à un état plus ancien de votre projet dans l'histoire du temps. Si vous vous trompez dans la dernière version ou si vous avez besoin d'améliorations dans un code plus ancien, vous souhaiterez peut-être créer une autre branche à partir de cet ancien instantané de projet pour ne pas gêner votre travail actuel. Voyons comment:
une. Répertoriez l'historique du projet et choisissez l'ancien ID de validation, commande:aller hist b. Créez une autre branche à partir de l'ID de validation:
git checkout -b ancien état e7aa9a5
c. Continuez à travailler sur le code, puis fusionnez / rebasez avec la branche «maître».
Récupérer une branche locale supprimée
Il est possible de régénérer le travail perdu sur une branche de référence. Dites, j'ai supprimé la branche 'old_code' sans fusionner avec la branche principale et j'ai perdu le travail. Et non, je n'ai pas non plus poussé la branche vers un référentiel distant, et alors? Eh bien, git suit et garde une entrée de journal de tous les changements effectués sur chaque référence, voyons le mien:aller reflog
Donc, HEAD @ {2} est le pointeur lorsque je suis passé à la branche 'old_code', récupérons cela:
Syntaxe:git checkout -b
Commander:git checkout -b ancien_code HEAD @ {2}
Vous devez être maintenant dans la branche 'old_code' avec votre dernier travail au moment de sa création. De plus, le pointeur 'reflog' à HEAD @ {1} était le récent commit effectué sur la branche 'old_code'. Pour restaurer cet unique commit exécutez simplement la commande comme:git reset --hard HEAD @ {1}.Cela restaure également les fichiers modifiés dans le répertoire de travail.
Si vous souhaitez connaître en détail le fonctionnement de cette commande et comment gérer les entrées 'reflog', vous pouvez aussi lire mon article précédent surrécupérer la branche supprimée de git reflog.
Annuler les modifications effectuées dans un commit
allerrevenirest utilisé pour enregistrer de nouveaux commits pour inverser l'effet de certains commits précédents.
Syntaxe: git revert
À partir de mes journaux de validation, je voudrais annuler la modification effectuée dans l'ID de validation en surbrillance:
Commander: git revert 827bc0d
Il est préférable de ne pas réinitialiser «–hard» les commits partagés, mais plutôt de les «git revert» pour conserver l'historique afin qu'il devienne plus facile pour tous de retrouver les journaux d'historique pour savoir ce qui a été annulé, par qui et pourquoi?
Vous pouvez utiliser la même logique pour référencer les commits concernant le pointeur HEAD au lieu de donner l'ID de commit, comme dans HEAD ~ 3 ou HEAD ~ 4 et ainsi de suite.
A donné un mauvais nom à ma succursale
Vous pouvez renommer un nom de branche locale. Il arrive souvent que vous souhaitiez renommer votre branche en fonction du problème sur lequel vous travaillez sans avoir à migrer tout votre travail d'un emplacement à un autre. Par exemple, vous pouvez être sur la même branche ou une branche différente et être toujours en mesure de renommer la branche souhaitée comme indiqué ci-dessous:
Syntaxe: git branche -m
Commander: git branche -m ancien_code ancien_ # 4920
Comme vous vous demandez peut-être est-ce que git garde une trace de ce changement de nom? Oui, cela fait référence à vos entrées 'reflog', voici la mienne:
Renommer une branche n'affectera pas sa branche de suivi à distance. Nous verrons dans la section distante comment remplacer une branche sur le référentiel distant
Réorganisez les journaux d'historique avant de pousser vers la télécommande
Comment j'aurais souhaité avoir fait certains engagements plus tôt que d'autres et ne pas avoir fait du tout certains engagements. Réorganisez et modifiez de manière interactive les anciens commits pour corriger ou améliorer efficacement le code
Syntaxe: git rebase -i
Commander: git rebase -i fb0a90e–Start rebasing les commits qui ont été faits après le commit-id fb0a90e
Revisitez le git rebase documentation pour comprendre en quoi un rebase «–interactif ou -i» est différent d’un rebase normal.
Validation des modifications non liées en un seul commit
Dans ce cas, vous devez diviser un ancien commit enterré en plusieurs commits logiques.
Syntaxe: git rebase -i
Commander: git rebase -i fb0a90e
Dans l'éditeur de rebase, vous devez choisir l'ID de validation e7aa9a5 et le changer en 'edit' au lieu de 'pick'.
Vous seriez maintenant dans la version du projet de commit id-e7aa9a5. Tout d'abord, réinitialisez l'historique de validation et la zone de préparation à la commande de validation précédente:git reset HEAD ~ 1
Deuxièmement, éditez + étape + validez les fichiers individuellement
Commandes:
git add code && git commit -m 'Ajout des codes initiaux'
git add newcode && git commit -m 'Ajout d'un nouveau code'
Troisièmement, continuez le rebase et terminez.
Commander :git rebase --continuer
Quatrièmement, affichez l'historique avec des commits supplémentaires.
Commander: aller hist
Modifier l'email de l'auteur dans tous les commits sur toutes les branches
Je contrôle les versions et valide les fichiers de mon projet dans git depuis longtemps maintenant, mais jusqu'à présent, il ne m'a jamais semblé que mon identifiant de messagerie ait été compromis dans mes journaux d'historique de validation qui sont même publiés sur des référentiels distants. Eh bien, cela peut arriver à n'importe qui lorsque vous configurez initialement les configurations dans le fichier «.gitconfig». À mon avis, git peut récrire les variables d'environnement que nous fournissons lors de la création d'un objet de validation.
J'obtiens d'abord la liste des identifiants de messagerie pour décider de ceux que je veux changer:
Commander: git log --all --pretty = format: '% an% d'–Ceci imprime le nom de l'auteur (refname / branch-name)
Deuxièmement, je traverse chaque commit sur chaque branche et réécrivez l'objet de validation avec le nouvel identifiant de messagerie
Commander:
git filter-branch --env-filter '
si ['$ GIT_AUTHOR_NAME' = 'divya']
puis
GIT_AUTHOR_EMAIL = 'divya@github.com'
être
' -- --tout
Fichiers perdus et trouvés
Supposons que vous ayez perdu un certain fichier et que vous ne vous souveniez pas de son nom, mais que vous puissiez vous rappeler certains mots du fichier. Dans ce cas, vous pouvez suivre ces étapes-
Étape 1: Répertoriez tous les commits qui ont contenu l'instantané de fichier avec le modèle recherché
Commander :git rev-list --all | xargs git grep -i 'horodatage'
Étape 2 : Créez une nouvelle branche 'perdue-trouvée' à partir de cet identifiant de validation en surbrillance
Syntaxe: git checkout -b perdu-trouvé d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f
J'ai oublié quelle branche a mon commit-id
Parfois, après avoir détecté un identifiant de commit bogué, vous pouvez aussi vouloir connaître toutes les branches qui ont ce commit sur eux afin de pouvoir les corriger toutes. Vérifier l’historique de chaque branche n’est pas très pratique dans un grand projet multi-branches.
Un mauvais commit effectué dans mon application de création de navigation a une fois cassé le code, c'est à ce moment-là que j'ai utilisé le Commande 'git bisect' pour détecter l'ID de validation qui était incorrect suivi ducommander:git branch - contientpour lister les branches avec ce mauvais commit.
Donc, maintenant que je connais toutes les branches qui ont encore le mauvais commit, je pourrais soit revenir soit réinitialiser cet ensemble de modifications.
Supprimer un commit de l'historique
Parfois, je ressens le besoin d'effacer un commit de l'historique et de ne laisser aucune trace. Je ne vous recommanderais pas d'essayer cette cascade sur une branche partagée mais uniquement sur votre branche locale.
Syntaxe: git rebase -i
Commander :git rebase -i 93859d8
Dans l'éditeur de rebase -> remplacez «edit» par «drop» pour l'ID de validation en surbrillance: 69f4813
Dans certains cas, cette réécriture peut entraîner des conflits. Vous devez résoudre les conflits, puis continuer.
Attention : Il s'agit d'une commande dangereuse car elle réécrit l'historique et peut perdre des données.Une telle branche diffère de son homologue distant et devra être poussée avec le--Obligerou--force-avec-bailoption.
Poussé une mauvaise branche vers la télécommande
Maintenant, voici ce que je veux faire - je veux supprimer un succursale distante et arrêtez également de le suivre depuis ma succursale locale. »git push«Commande lorsqu'elle est utilisée avec le--effacerL'option supprime la branche distante Donc, voici comment j'obtiens la copie locale du projet cloné -
git clone https://github.com/greets/myProj.git
cd myProj
Une fois, la branche distante est supprimée, les autres sur le référentiel partagé doivent actualiser et mettre à jour leurs références distantes avec le--pruneoption pour supprimer les références d'objet manquantes:git fetch --prune -v origine
Dans cet article, j'ai mentionné certaines des erreurs courantes ou des modifications que git peut vous aider à corriger. Chaque code est unique et développé à sa manière, il existe donc différentes façons d'aborder et de résoudre un problème. Vous pouvez toujours vous référer au fonctionnaire documentation git pour comprendre comment diverses commandes git protègent votre code source et comment utiliser les commandes de la meilleure façon possible.
Maintenant que vous avez compris les erreurs courantes de Git, regardez ceci par Edureka, une entreprise d'apprentissage en ligne de confiance avec un réseau de plus de 250 000 apprenants satisfaits répartis dans le monde entier. Le cours de formation à la certification Edureka DevOps aide les apprenants à comprendre ce qu'est DevOps et à acquérir une expertise dans divers processus et outils DevOps tels que Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack et GIT pour l'automatisation de plusieurs étapes dans SDLC.
Vous avez une question pour nous? Veuillez le mentionner dans la section des commentaires de ces «erreurs Git courantes» et nous vous répondrons