Fusions qui ne semblent pas être prises en compte

Et je me fais bénir par les collègues…

Le problème exposé dans ce sujet a été résolu.

Bonsoir,

J'ai apparemment un souci dans mon utilisation de git, et ça commence à courir sur les nerfs des autres collaborateurs…

Comme souvent, je bricole en local, et je récupère au fur et à mesure les modifications depuis l'origine avec des pulls (j'utilise EGit).

Quand il y a des lignes modifiées et chez moi et sur l'origine, évidemment, ça me fait des conflits. Je les fusionne à la main, donc je compare le HEAD avec ma copie de travail, et je reprends les modifications apportées. Du moins c'est ce que je pensais…
Ensuite, j'enregistre les modifications, je re-vérifie les modifications entre le HEAD et ma nouvelle version locale, reprend les éventuelles modifications que j'avais loupées, etc., jusqu'à ce que je sois satisfait. J'ajoute donc le fichier signalé comme conflictuel à mon index, je traite les autres fichiers en conflit de la même manière, puis le fais le merge commit manuellement. D'ailleurs, EGit me met par défaut le message standard de merge commit, avec en plus la liste des fichiers conflictuels.

Dernièrement, j'ai poussé mes modifications vers l'origine, et il est apparu que j'ai écrasé des modifications des autres utilisateurs… J'avoue que je ne vois pas ce que j'ai fait de faux, est-ce que quelqu'un pourrait mettre le doigt sur mon erreur ?

Merci d'avance

P.S. : j'ai mis ici, même si je gère du dev' web avec Git pour le cas, mais ce n'est pas un problème qui y soit directement lié. Et "Système et matériel" ne me paraît pas non-plus approprié, mais je peux me tromper. Si jamais, je pense que vous pouvez signaler le sujet pour qu'il soit déplacé de "Programmation" vers un forum mieux adapté.

+0 -0

Hello,

plutôt qu'un pull, pense à ajouter une option poru rebase au passage via git pull --rebase (c'est l'équivalent d'un git fetch origin et git rebase origin/nom-de-la-branche). Si tu as des modifs en cours, pense à les stasher avant via un git stash.

Si tu as des conflits lors de cette action, c'est que le code d'origine (présent chez les autres et sur le remote) a changé et que git n'arrive pas à appliquer tes modifs ; du coup tu peux mettre à jour en toute quiétude. :)

+2 -0

Merci Talus

Hello,

plutôt qu'un pull, pense à ajouter une option poru rebase au passage via git pull --rebase (c'est l'équivalent d'un git fetch origin et git rebase origin/nom-de-la-branche). Si tu as des modifs en cours, pense à les stasher avant via un git stash.

Talus

En gros, si j'ai des modifs que je ne souhaite pas faire de push, je dois faire stash plutôt que commit avant de faire un pull ?

Si tu as des conflits lors de cette action, c'est que le code d'origine (présent chez les autres et sur le remote) a changé et que git n'arrive pas à appliquer tes modifs ; du coup tu peux mettre à jour en toute quiétude. :)

Talus

Juste pour être certain : l'action dont il est mention ici, c'est le stash ou le pull --rebase ?

+0 -0

Il y a une chose que je ne comprends pas. C'est dans le workflow standard de travailler avec commit et push ainsi que pull et fetch, donc je m'attendrais à ce que les conflits puissent être gérés dans ce flux, non ?

+0 -0

ils le sont… je comprends pas ta remarque ? Si y'a un conflit, git te demande de les fixer, et habituellement il el fait par un merge

Ce qui est pas propre en soit, car peut detruire un travail qui n'a pas été pensé par toi à la base. Alors que lors tu fais un rebase (via fetch + rebase ou pull --rebase), si tu as des conflits, c'est juste des modifs que t'as apporté qui sont pas correct et qui n'influent pas sur le travail déjà apporté. C'est ce qu'on appelle garder un arbre linéairement propre

+0 -0

En fait, je crois que j'ai finalement compris mon problème : la vue de merge d'EGit n'enregistre apparemment pas les modifications dans le fichier local, alors que l'affichage semble montrer que c'est le cas (disparition de l'astérisque, indice courant pour dire si le fichier a été sauvegardé ou non). Donc je gérais correctement la fusion, mais au moment où j'ajoutais le fichier à mon index, celui-ci ne comprenait que mes modifications…

Et pour ne rien simplifier, EGit ne propose pas de commande de stash simplement accessible sinon dans une perspective1 obscure. Pas très malin de leur part, je trouve…


  1. Dans Eclipse, l'arrangement des différents onglets et parties de l'IDE selon une utilisation est appelé perspective 

+0 -0

En fait, je crois que j'ai finalement compris mon problème : la vue de merge d'EGit n'enregistre apparemment pas les modifications dans le fichier local, alors que l'affichage semble montrer que c'est le cas (disparition de l'astérisque, indice courant pour dire si le fichier a été sauvegardé ou non)

Ah j'avais pas pensé que c'était ce soucis là.

Oui j'ai aussi ce problème aveec Egit. Ce plugin est totalement buggé.

Et oui, passer par la vue Git Staging permet de passer outre bien des emmerdements, mais ne solutionne pas tout.

Notamment quelques merges assez sauvages, ou le fait qu'importer un projet git ne le synchronise pas toujours (faut faire Team -> Share…).

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte