Comment résoudre les conflits dans EGit
J'utilise EGit sur Eclipse v4. (Kepler). Je veux m'engager et pousser mes modifications. Je fais un pull en premier et un fichier est en conflit. Après avoir résolu manuellement le conflit (local et distant sont les mêmes maintenant), je rencontre toujours des problèmes.
Voici les messages d'erreur pour chaque action:
Pousser en amont
master: master [rejeté - sans avance rapide]
Tirer
Impossible d'extraire dans un référentiel avec l'état suivant: MERGING_RESOLVED
Marquer comme fusionné
Échec de l'ajout de la ressource à l'index Échec de l'ajout de la ressource à l'index Une exception a été interceptée lors de l'exécution de la commande add
Réinitialisation matérielle
Une erreur interne s'est produite lors de: "Réinitialisation des références/têtes/maîtres". Exception interceptée lors de l'exécution de la commande de réinitialisation. {0}
Comment puis-je supprimer le conflit et pousser mes modifications? Qu'est-ce que je fais mal?
Utilisez-vous la vue Synchroniser l’équipe? Si oui, c'est le problème. La résolution des conflits dans la vue Synchronisation d’équipe ne fonctionne pas avec EGit. Au lieu de cela, vous devez utiliser la vue Git Repository.
Ouvrez la perspective Git. Dans la vue Git Repository, allez sur on Branches → Local → master et faites un clic droit → Fusionner ...
Il devrait sélectionner automatiquement Suivi à distance → Origin/master. presse Merge.
Il devrait montrer result:conflict.
Ouvrez les fichiers en conflit. Ils doivent avoir un vieux conflit de fusion de style sk000l >>> = ===== <<<< dans les fichiers. Editez le fichier pour résoudre le conflit, puis enregistrez.
Désormais, dans la vue "Mise en scène Git", le fichier modifié doit apparaître dans "Modifications non mises en scène". Clic droit et ' ajouter à l'index '
Répétez l'opération pour tous les fichiers restants.
Maintenant, dans la vue "Mise en scène git", validez et envoyez. Comme Git/Eclipse sait maintenant que vous avez fusionné les modifications d'origine distantes dans votre maître, évitez l'erreur de non-transfert rapide.
Je trouve également difficile de résoudre les conflits de fusion dans EGit. Lorsque je suis prêt à valider certaines modifications dans un référentiel partagé, les étapes que j'ai apprises sont les suivantes:
- Faites un clic droit sur le projet et choisissez Equipe: S'engager ....
- Passez en revue mes modifications pour vérifier que je n'ai pas validé les modifications que j'ai apportées par inadvertance ou des modifications non liées que j'ai oubliées. Rédigez le message de validation pendant que je vérifie les modifications.
- Je suis optimiste et je commence donc par cliquer sur le bouton Valider et appuyer. Si personne d'autre n'a poussé les changements, j'ai fini. Si quelqu'un le fait, la validation réussit et le Push est rejeté.
- Faites un clic droit sur le projet et choisissez Équipe: Pull. S'il n'y a pas de conflits, choisissez Team: Push to Upstream et j'ai terminé.
- S'il y a des conflits, regardez dans l'explorateur de paquets pour voir quels fichiers sont en conflit. Cliquez avec le bouton droit sur chaque fichier en conflit et choisissez Equipe: Outil de fusion. Il montrera toutes les modifications dans les deux versions du fichier, les conflits apparaissant en rouge. Cliquez sur le bouton pour fusionner toutes les modifications non conflictuelles, puis modifiez manuellement les sections rouges. Il y a aussi un bouton pour montrer une fusion à trois qui inclut l'ancêtre commun.
- Enregistrez les modifications dans le fichier. Si vous le souhaitez, vous pouvez le comparer à HEAD pour voir les modifications que vous apportez en plus des modifications que vous venez d'extraire.
- Cliquez avec le bouton droit sur le fichier et choisissez Equipe: Ajouter à l'index pour indiquer à EGit que vous avez fini de fusionner ce fichier. Pour moi, il s'agit de l'étape la moins intuitive, mais la ligne de commande de git utilise également la commande add pour indiquer qu'une fusion est terminée.
- Répétez l'opération pour tous les autres fichiers en conflit.
- Lorsque tous les fichiers sont fusionnés, cliquez avec le bouton droit de la souris sur le projet et choisissez Équipe: Rebase: Continuer Rebase. S'il y a plus de commits en conflit, revenez à la gestion des conflits.
- Lorsque la base est terminée, lancez vos tests pour voir que la base n'a rien cassé.
- Faites un clic droit sur le projet et choisissez Équipe: Push to Upstream.
Ce guide m'a été utile http://wiki.Eclipse.org/EGit/User_Guide#Resolving_a_merge_conflict .
MISE À JOUR Juste une note à ce sujet à propos de ma procédure, voici comment je procède:
- Commettre mon changement
- Fetch (espace de travail Syncrhonize)
- Tirer
- Gérer les conflits avec l'outil de fusion (Team-> Outil de fusion) et enregistrer
- Ajouter chaque fichier à la scène (Équipe -> Ajouter à l'index)
- Maintenant, le message de validation dans la fenêtre d'étape est pré-rempli avec "XXX fusionné". Vous pouvez laisser tel quel ou changer le message de validation
- S'engager et pousser
C'est dangereux dans certains cas, mais il est très utile d'éviter d'utiliser des outils externes comme Git Extension ou Source Tree.
Je sais que c’est un article plus ancien, mais j’ai été frappé par un problème similaire et j’ai réussi à le résoudre. J’ai donc pensé partager.
(Mise à jour: Comme indiqué dans les commentaires ci-dessous, cette réponse était antérieure à l'inclusion de la fonctionnalité "git stash" dans eGit.)
Ce que j'ai fait était:
- Copiez la copie locale du fichier en conflit, avec ou sans modification de la version en amont.
- Dans Eclipse, "Rétablissez" le fichier dans la version juste avant le conflit.
- Exécutez un "Pull" à partir du référentiel distant, permettant à toutes les modifications d'être synchronisées vers le répertoire de travail local. Cela devrait effacer les mises à jour de votre système de fichiers, ne laissant que ce qu'il vous reste à pousser.
- Vérifiez la version actuelle du fichier en conflit dans votre répertoire de travail avec la copie que vous avez copiée. S'il y a des différences, effectuez une fusion appropriée des fichiers et validez cette version du fichier dans le répertoire de travail.
- Maintenant, "Poussez" vos modifications.
J'espère que ça t'as aidé.
Faites un clic droit sur un fichier en conflit et ajoutez-le à l'index après la résolution des conflits.
Comme il s’agit d’un problème auquel nous sommes souvent confrontés, voici les étapes à suivre pour le résoudre.
Ouvrez la perspective Git. Dans la vue Git Repository, allez à on Branches → Local → maître et faites un clic droit → Fusion ...
Il devrait sélectionner automatiquement suivi à distance → * Origine/maître. presse Merge.
Lancer la vue de la scène dans Eclipse.
Double-cliquez sur les fichiers ayant initialement présenté un conflit.
Dans la vue Fusion de conflits, en sélectionnant la flèche gauche pour toutes les modifications non conflictuelles + conflit de gauche à droite, vous pouvez résoudre tous les conflits.
Enregistrez le fichier fusionné.
Faire une équipe → tirer à nouveau de Eclipse.
Vous êtes prêt :)
Un processus antérieur de résolution de conflits (via la vue intermédiaire) dans Eclipse semblait beaucoup plus intuitif il y a plusieurs années. Par conséquent, soit l'outil ne fonctionne plus comme je le connaissais, soit je me souviens du processus de résolution des conflits de fusion dans - SVN référentiels. Quoi qu'il en soit, il y avait cette option de menu "Marquer comme fusionné" astucieux lorsque vous cliquez avec le bouton droit sur un fichier en conflit.
Avance rapide jusqu'en 2019, j'utilise la vue "Git Staging" dans Eclipse (v4.11). En fait, j'utilise STS (Spring Tool Suite 3.9.8), mais je pense que la vue Git Staging est un plug-in Eclipse standard permettant de travailler avec Java/Spring. projets à base de. Je partage l'approche suivante au cas où cela aiderait quelqu'un d'autre et parce que je me lasse ou que je résous les conflits de fusion à partir de la ligne de commande GIT. ;-)
Comme la fonctionnalité dont je me souviens est maintenant partie (ou peut-être différemment avec la version actuelle de GIT et Eclipse), voici la procédure que je suis en train de suivre pour résoudre les conflits de fusion via Eclipse à l'aide d'un référentiel GIT. Cela me semble le plus intuitif. De toute évidence, le nombre de réponses indique clairement qu'il existe de nombreuses façons de résoudre les conflits de fusion. Peut-être ai-je juste besoin de passer à JetBrains IntelliJ, avec leur outil de fusion à trois voies.
- Double-cliquez sur le fichier incriminé
- Une interface "Comparaison de texte" apparaît, avec des vues côte à côte des validations en conflit.
- Identifiez la vue correspondant à l'état local du fichier ou à la validation la plus récente.
- Modifiez la fenêtre locale en ajoutant ou en rédigeant les modifications du commit en question.
- Lorsque l'ensemble des modifications souhaitées a été examiné et mis à jour, cliquez avec le bouton droit sur le fichier non mis en scène.
- Cliquez sur l'option "Ajouter à l'index" et votre fichier sera ajouté aux modifications planifiées.
- Cela supprime également le fichier en conflit de la liste non mise en place, indiquant ainsi qu'il a été "marqué comme étant fusionné".
- Continuez ce processus avec chaque fichier supplémentaire en conflit.
- Lorsque vous avez réactivé tous les fichiers en conflit, vérifiez que tous les fichiers souhaités (y compris les modifications supplémentaires) sont gérés.
- Ajoutez un message de validation approprié.
- Commettez et poussez les fichiers "fusionnés" dans le référentiel Origin, ce qui marque officiellement vos fichiers comme étant fusionnés.
REMARQUE: les options de menu n'étant pas intuitives, un certain nombre d'éléments peuvent être trompeurs. Par exemple, si vous avez enregistré des mises à jour localement et essayez de rouvrir le fichier en conflit pour confirmer et que les modifications apportées ont persisté, la confusion peut survenir car l'état de conflit d'origine est ouvert ... pas vos modifications.
Mais une fois que vous avez ajouté le (s) fichier (s) à l'index, vos modifications y sont affichées.
Je recommande également que, lorsque vous récupérez des modifications qui entraînent un conflit de fusion, vous "stockiez" d'abord vos modifications locales, puis réintégrez les modifications. Au moins avec GIT, à titre de protection, vous ne serez pas autorisé à intégrer des modifications externes tant que vous ne les annulez pas ou que vous ne les stockez pas. Supprimez et revenez à l'état HEAD si les modifications ne sont pas importantes, mais stockez-les sinon.
Enfin, si vous ne modifiez qu’un ou deux fichiers, envisagez de les extraire en tant que référence dans des fichiers texte séparés, puis revenez à l’option HEAD), puis mettez à jour manuellement le ou les fichiers lorsque vous extrayez le fichier. changements à travers.
Cette approche est similaire à la solution "stash" mais je pense qu'elle pourrait être plus claire:
- Votre branche locale actuelle est "maître" et vous avez des modifications locales.
- Après la synchronisation, il y a des modifications entrantes et certains fichiers doivent être fusionnés.
- La première étape consiste donc à basculer vers une nouvelle succursale locale (par exemple, "my_changes"):
- Equipe -> Basculer vers -> Nouvelle branche
- Nom de la branche: my_changes (par exemple)
- Equipe -> Basculer vers -> Nouvelle branche
- Après le basculement vers la nouvelle branche, les modifications locales non validées existent toujours. Alors, validez toutes vos modifications locales non validées dans la nouvelle branche "my_changes":
- Revenez à la branche "maître" locale:
- Équipe -> Basculer vers -> maître
- Désormais, lorsque vous choisissez Equipe -> Synchroniser Workspace, aucun fichier de "fusion" ne doit apparaître.
- Sélectionnez l’équipe -> tirer
- Maintenant, la branche "maître" locale est à jour par rapport à la branche "maître" distante.
- Maintenant, il y a deux options:
- Option 1:
- Sélectionnez Equipe -> Fusionner pour fusionner les modifications locales originales de la branche locale "my_changes" en une branche locale "maître".
- Maintenant, validez les modifications entrantes de l'étape précédente dans la branche "maître" locale et transmettez-les à la branche "maître" distante.
- Option 2:
- Basculez à nouveau vers la branche locale "my_changes".
- Fusionner les mises à jour de la branche "maître" locale dans la branche "my_changes".
- Continuez avec la tâche en cours dans la branche "my_changes".
- Lorsque la tâche est terminée, utilisez l'option 1 ci-dessus pour mettre à jour la branche "principale" locale ainsi que la branche distante.
- Option 1:
Pour résoudre les conflits, utilisez Git Stash pour éviter les modifications non validées. puis déroulez le groupe de modifications du référentiel distant; puis ouvrez votre réserve locale pour réappliquer vos modifications non validées.
Dans Eclipse v4.5 (Mars) pour masquer les modifications (un ajout relativement récent ne figurait pas dans l'EGit précédent), procédez comme suit: faites un clic droit sur un projet Eclipse de niveau supérieur situé dans le contrôle Git, choisissez Équipe , choisissez Stashes , sélectionnez Modifications de Stash ; une boîte de dialogue s'ouvre pour demander un message de validation de dissimulation.
Vous devez utiliser le menu contextuel sur un projet de niveau supérieur! Si je clique avec le bouton droit sur un répertoire ou un fichier dans un projet contrôlé par Git, je ne reçois pas le menu contextuel approprié.