Le message d'erreur " Vos modifications locales sur les fichiers suivants seront écrasées par fusion " apparaît dans le mécanisme de contrôle de version de Git. Cette erreur se produit si vous avez modifié un fichier contenant également des modifications dans le référentiel distant.

Erreur Git: vos modifications locales sur les fichiers suivants seront écrasées par la fusion

Ce message d'erreur est évité SI il n'y a pas de fichiers non validés ayant é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 dépôts? Qu'est-ce que pousser et tirer 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. Un « Pull» signifie que vous extrayez 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 tirage, vous apportez des modifications au code ou ajoutez des fonctionnalités supplémentaires. Une fois que vous avez terminé, vous « insérez» le code dans le référentiel afin que les modifications soient enregistrées et les ajouts effectués. Le code est également accessible à d'autres personnes.

Si vous débutez dans le contrôle de version de Github, il est recommandé de passer en revue toutes les bases. Dans cet article, nous supposons que vous avez déjà des connaissances de base et que vous connaissez tous les détails.

Comment réparer "Les modifications locales apportées aux fichiers suivants seront écrasées par la 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. Vous pouvez également enregistrer vos modifications locales dans une réserve et extraire la version à partir 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 la même page avant de poursuivre. Si vous commettez mal ou poussez la mauvaise version, cela pourrait affecter toute l'équipe.

Méthode 1: Forcer un pull à écraser les modifications locales

Si vous ne vous souciez pas des modifications apportées localement et que vous voulez obtenir le code du référentiel, vous pouvez forcer un tirage. Cela écrasera toutes les modifications locales effectuées sur votre ordinateur. Une copie de la version du référentiel apparaîtra en double.

Exécutez les commandes suivantes dans votre IDE:

 réinitialisation de git - tir dur 

Cela détruira instantanément tous vos changements locaux, alors assurez-vous de savoir ce que vous faites et n'avez pas besoin de vos changements locaux.

Méthode 2: conserver les deux modifications (locales et à partir du référentiel)

Si vous souhaitez conserver les deux modifications (modifications effectuées localement et 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 du milieu. aucune modification ne sera perdue jusqu'à ce que vous les supprimiez manuellement.

 git add $ the_file_under_error git commit git pull 

Lorsque vous obtenez un conflit de fusion, ouvrez ces outils de résolution de conflits et vérifiez ligne par ligne.

Méthode 3: Conserver les deux modifications MAIS ne pas valider

Cette situation se produit de temps à autre lorsque les développeurs ne sont pas prêts à valider car il existe un code partiellement défectueux en cours de débogage. Ici, nous pouvons stocker les modifications en toute sécurité, extraire la version du référentiel, puis extraire 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 réserve, vous devez les résoudre de la manière habituelle. Vous pouvez également utiliser la commande:

 git stash s'applique 

au lieu de pop si vous n'êtes pas prêt à perdre le code bloqué en raison de conflits.

Si la fusion ne vous semble pas une option viable, envisagez une refonte. La redistribution est le processus consistant à déplacer ou à combiner une séquence de validations vers une nouvelle validation de base. En cas de changement de base, remplacez le code par:

 git stash git pull - origine origine maître git stash pop 

Méthode 4: apportez 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 valider tout ce que vous ne souhaitez pas écraser, puis suivez la méthode 3. Vous pouvez utiliser la commande suivante pour les modifications que vous avez effectuées. vouloir écraser à partir de la version présente dans le référentiel:

 chemin de sortie git / to / file / to / revert 

ou

 git checkout HEAD ^ chemin / vers / fichier / vers / retour 

En outre, vous devez vous assurer que le fichier n'est pas mis en scène via:

 git réinitialiser le chemin HEAD / vers / file / vers / revert 

Ensuite, passez à la commande pull:

 git pull 

Cela tentera ensuite d'extraire la version du référentiel.