Le message d'erreur ' Vos modifications locales apportées aux fichiers suivants seront écrasées par fusion »Se produit dans le mécanisme de contrôle de version de Git. Cette erreur se produit si vous avez modifié un fichier qui comporte également des modifications dans le référentiel distant.
Erreur Git: vos modifications locales apportées aux fichiers suivants seront écrasées par fusion
Ce message d'erreur est évité SI il n'y a pas de fichiers non validés qui ont également des modifications dans le référentiel distant. Lorsque vous rencontrez ce message, il est préférable de consulter les autres membres de votre équipe et de demander leur avis. Que vous souhaitiez fusionner vos modifications locales ou conserver la version présente dans le référentiel, il est préférable de garder tout le monde à bord.
Que sont les référentiels? Que sont les push and pull dans Git?
Un référentiel est une sorte de stockage de code qui est constamment modifié et obtenu par les membres de l'équipe via le mécanisme de contrôle de version de GitHub. UNE ' Tirer' signifie que vous tirez la dernière version du référentiel sur votre stockage local / IDE (environnement de développement intégré) tel que Pycharm, etc.
Après un Pull, vous apportez des modifications au code ou ajoutez plus de fonctionnalités. Une fois que vous avez terminé, vous Pousser' le code sur le référentiel afin que les modifications soient enregistrées et que des ajouts soient effectués. Le code est également accessible à d'autres personnes.
Si vous êtes nouveau dans le contrôle de version Github, il est recommandé de passer d'abord par toutes les bases. Dans cet article, nous supposons que vous avez déjà des connaissances de base et que vous connaissez tous les tenants et aboutissants.
Comment réparer 'Vos modifications locales apportées aux fichiers suivants seront écrasées par fusion'?
La résolution de ce message d'erreur dépend de ce que vous voulez faire. Vous pouvez ignorer vos modifications locales et extraire celles du référentiel ou enregistrer vos modifications locales dans une réserve et extraire la version du référentiel. Tout dépend de vos préférences.
Par conséquent, nous vous recommandons de consulter les membres de votre équipe et de vous assurer que vous êtes tous sur le même page avant d'aller de l'avant. Si vous vous engagez à tort ou si vous utilisez la mauvaise version, cela pourrait affecter toute l'équipe.
Méthode 1: Forcer un pull pour écraser les modifications locales
Si vous ne se soucient pas des changements effectués localement et que vous souhaitez obtenir le code du référentiel, vous pouvez forcer une extraction. Cela écrasera toutes les modifications locales effectuées sur votre ordinateur, une copie en double de la version dans le référentiel apparaîtra.
Exécutez les commandes suivantes dans votre IDE:
git reset - hard git pull
Cela détruira instantanément toutes vos modifications locales, alors assurez-vous de savoir ce que vous faites et de ne pas avoir besoin de vos modifications locales.
Méthode 2: conserver les deux modifications (locales et provenant du dépôt)
Si vous souhaitez conserver les deux modifications (modifications effectuées localement et modifications présentes dans le référentiel), vous pouvez ajouter et valider vos modifications. Lorsque vous tirez, il y aura évidemment un conflit de fusion. Ici, vous pouvez utiliser les outils de votre IDE (tels que Difftool et mergetool) pour comparer les deux morceaux de code et déterminer les modifications à conserver et celles à supprimer. C'est la voie médiane; aucune modification ne sera perdue tant que vous ne les supprimerez pas manuellement.
git add $ the_file_under_error git commit git pull
Lorsque vous obtenez un conflit de fusion, affichez ces outils de résolution de conflit et vérifiez ligne par ligne.
Méthode 3: conserver les deux modifications MAIS ne pas valider
Cette situation se produit de temps en temps lorsque les développeurs ne sont pas prêts à s'engager car il y a du code partiellement cassé que vous déboguez. Ici, nous pouvons cacher les modifications en toute sécurité, extraire la version du référentiel, puis désinstaller votre code.
git stash save --keep-index
ou
git stash
git pull git stash pop
S'il y a des conflits après avoir ouvert la cachette, vous devez les résoudre de la manière habituelle. Vous pouvez également utiliser la commande:
git stash apply
au lieu de pop si vous n'êtes pas prêt à perdre le code caché en raison de conflits.
Si la fusion ne semble pas être une option viable pour vous, envisagez de procéder à un rebase. Le rebasage est le processus de déplacement ou de combinaison d'une séquence de commits vers un nouveau commit de base. Dans le cas du rebasage, changez le code en:
git stash git pull --rebase origin master git stash pop
Méthode 4: apporter des modifications à des parties «spécifiques» de votre code
Si vous souhaitez apporter des modifications à des parties spécifiques du code et ne souhaitez pas tout remplacer, vous pouvez commettre tout ce que vous ne voulez pas écraser, puis suivez la méthode 3. Vous pouvez utiliser la commande suivante pour les modifications que vous souhaitez écraser à partir de la version présente dans le référentiel:
chemin d'extraction git / vers / fichier / vers / revert
ou
git checkout HEAD ^ chemin / vers / fichier / vers / retour
De plus, vous devez vous assurer que le fichier n'est pas mis en scène via:
git reset HEAD path / to / file / to / revert
Ensuite, exécutez la commande pull:
git pull
Cela tentera ensuite de récupérer la version du référentiel.
3 minutes de lecture
