Résoudre un conflit Git avec des fichiers binaires

Question

J'utilise Git sous Windows (msysgit) pour suivre les modifications apportées au travail de conception que j'ai effectué.

Aujourd'hui, je travaille sur un autre PC (avec référentiel à distance brian) et j'essaie maintenant de fusionner les modifications apportées aujourd'hui dans ma version locale habituelle sur mon ordinateur portable.

Sur mon ordinateur portable, j'ai utilisé git pull brian master pour intégrer les modifications dans ma version locale. Tout se passait bien, à l'exception du document principal InDesign. Cela se traduit par un conflit.

La version sur le PC (<=>) est la dernière que je souhaite conserver mais je ne sais pas quelles commandes indiquent au référentiel de l’utiliser.

J'ai essayé de copier directement le fichier sur mon ordinateur portable, mais cela semble interrompre tout le processus de fusion.

Quelqu'un peut-il m'indiquer la bonne direction?

Answer 1

git checkout accepte une option --ours ou --theirs dans des cas comme celui-ci. Par conséquent, si vous avez un conflit de fusion et que vous savez que vous souhaitez uniquement importer le fichier de la branche dans laquelle vous fusionnez, vous pouvez le faire:

$ git checkout --theirs -- path/to/conflicted-file.txt

pour utiliser cette version du fichier. De même, si vous savez que vous voulez votre version (pas celle qui est fusionnée), vous pouvez utiliser

$ git checkout --ours -- path/to/conflicted-file.txt

Answer 2

Vous devez résoudre le conflit manuellement (copier le fichier sur), puis valider le fichier (que vous l'ayez copié ou utilisé avec la version locale) comme ceci

git commit -a -m "Fix merge conflict in test.foo"

Normalement, les envois automatiques se font après la fusion, mais lorsqu'il détecte des conflits, il ne peut pas résoudre tout seul, il applique tous les correctifs qu'il a détectés et vous laisse le reste à résoudre et à valider manuellement. La page de manuel de fusion de comptes , la Cours intensif Git-SVN ou cette entrée de blog pourrait nous éclairer sur la façon dont elle est censée fonctionner.

Modifier: consultez le message ci-dessous. Vous n'êtes pas obligé de copier les fichiers vous-même, vous pouvez utiliser

.

git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt

pour sélectionner la version du fichier que vous souhaitez. Copier / éditer le fichier ne sera nécessaire que si vous voulez un mélange des deux versions.

Veuillez marquer la réponse de mipadis comme étant la bonne.

Answer 3

Vous pouvez également résoudre ce problème avec

git mergetool

qui provoque git la création de copies locales du fichier binaire en conflit et la création de votre éditeur par défaut:

• {conflicted}.HEAD
• {conflicted}
• {conflicted}.REMOTE

Évidemment, vous ne pouvez pas modifier utilement les fichiers binaires dans un éditeur de texte. Au lieu de cela, vous copiez le nouveau fichier <=> sur <=> sans fermer l'éditeur. Ensuite, lorsque vous fermez l'éditeur, <=> verra que la copie de travail non décorée a été modifiée et que le conflit de fusion est résolu de la manière habituelle.

Answer 4

Pour résoudre le problème en conservant la version dans votre branche actuelle (ignorez la version de la branche dans laquelle vous fusionnez), ajoutez et validez le fichier:

git commit -a

Pour résoudre le problème en écrasant la version de votre branche actuelle par la version de la branche que vous fusionnez, vous devez d'abord récupérer cette version dans votre répertoire de travail, puis l'ajouter / la valider:

git checkout otherbranch theconflictedfile
git commit -a

Expliqué plus en détail

Answer 5

La réponse de Mipadi n'a pas fonctionné, il fallait que je fasse ceci:

  

git checkout - Votre chemin / vers / fichier.bin

ou, pour conserver la version fusionnée dans:

  

git checkout - leur chemin / vers / fichier.bin

puis

  

git add path / to / file.bin

Et puis j'ai pu faire & "git mergetool &"; à nouveau et continuez sur le prochain conflit.

Answer 6

À partir de la git checkout docs

  

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...

     

--ours
   --theirs
  Lorsque vous extrayez des chemins de l’index, recherchez les chemins non fusionnés à l’étape 2 (ours) ou 3 (theirs).

     

L'index peut contenir des entrées non fusionnées en raison d'une fusion précédente ayant échoué. Par défaut, si vous essayez d'extraire une telle entrée de l'index, l'opération d'extraction échouera et rien ne sera extrait. Utiliser -f ignorera ces entrées non fusionnées. Le contenu d'un côté spécifique de la fusion peut être extrait de l'index à l'aide de -m ou <=>. Avec <=>, les modifications apportées au fichier d'arborescence de travail peuvent être ignorées pour recréer le résultat de la fusion d'origine en conflit.

Answer 7

Cette procédure consiste à résoudre les conflits de fichiers binaires après avoir soumis une demande d'extraction à Github:

1. Sur Github, vous avez donc constaté que votre demande d'extraction était en conflit sur un fichier binaire.
2. Retournez maintenant à la même branche git sur votre ordinateur local.
3. Vous (a) reconstruisez / reconstruisez à nouveau ce fichier binaire et (b) validez le fichier binaire obtenu dans cette même branche git.
4. Ensuite, vous repoussez cette même branche git vers Github.

Sur Github, lors de votre demande d'extraction, le conflit devrait disparaître.

Answer 8

Je suis tombé sur un problème similaire (je voulais extraire une validation qui comprenait des fichiers binaires causant des conflits lors de la fusion), mais une solution différente qui peut être résolue entièrement avec git (c'est-à-dire ne pas avoir à copier manuellement les fichiers) . Je pensais l'inclure ici pour au moins pouvoir m'en souvenir la prochaine fois que j'en aurais besoin. :) Les étapes ressemblent à ceci:

% git fetch

Ceci récupère les dernières validations du référentiel distant (vous devrez peut-être spécifier un nom de branche distante, selon votre configuration), mais n'essaiera pas de les fusionner. Il enregistre le commit dans FETCH_HEAD

% git checkout FETCH_HEAD stuff/to/update

Ceci prend la copie des fichiers binaires que je veux et écrase ce qui est dans l’arbre de travail avec la version extraite de la branche distante. git n'essaie pas de fusionner, vous obtenez donc une copie exacte du fichier binaire de la branche distante. Une fois que cela est fait, vous pouvez ajouter / valider la nouvelle copie comme d'habitude.

Answer 9

J'ai rencontré deux stratégies de gestion de diff / fusion de fichiers binaires avec Git sous Windows.

1. Tortoise git vous permet de configurer des outils de différenciation / fusion pour différents types de fichiers en fonction de leur extension. Voir 2.35.4.3. Diff / Fusionner paramètres avancés http://tortoisegit.org/docs/tortoisegit/tgit- dug-settings.html . Cette stratégie repose bien sûr sur la disponibilité d’outils de différenciation / fusion adaptés.

2. En utilisant les attributs git, vous pouvez spécifier un outil / une commande pour convertir votre fichier binaire en texte, puis laisser votre outil diff / merge par défaut agir à sa place. Voir http://git-scm.com/book/it/ v2 / Personnalisation-Git-Git-Attributes . L'article donne même un exemple d'utilisation de métadonnées pour diff images.

J'ai eu les deux stratégies pour travailler avec des fichiers binaires de modèles de logiciels, mais nous sommes allés avec tortoise git car la configuration était facile.

Answer 10

Si le fichier binaire est quelque chose de plus qu'une dll ou quelque chose qui peut être modifié directement , comme une image ou un fichier de fusion (et vous n'avez pas besoin de supprimer / sélectionnez un fichier ou l’autre) une vraie fusion ressemblerait à ceci:

Je suggère de rechercher un outil de diff orienté vers le fichier binaire, par exemple, il existe des outils gratuits pour les fichiers image, par exemple

• npm install -g imagediff IIRC from https://github.com/uber/image-diff
• ou python https://github.com/kaikuehne/mirror.git
• il y en a d'autres

et comparez-les.

S'il n'y a pas d'outil de comparaison pour comparer vos fichiers, si vous disposez du générateur d'origine du fichier bin (, il existe un éditeur ). comme Blender 3D, vous pouvez ensuite inspecter manuellement ces fichiers, consulter les journaux et demander à l’autre personne ce que vous devez inclure) et effectuez une sortie des fichiers avec https: // git -scm.com/book/es/v2/Git-Tools-Advanced-Merging#_manual_remerge

$ git show :1:hello.blend > hello.common.blend $ git show :2:hello.blend > hello.ours.blend $ git show :3:hello.blend > hello.theirs.blend

Answer 11

J'utilise Git Workflow for Excel - https: //www.xltrail. com / blog / git-workflow-for-excel pour résoudre la plupart de mes problèmes de fusion liés aux fichiers binaires. Cette application open source m'aide à résoudre les problèmes de manière productive sans perdre de temps et me permet de choisir la bonne version du fichier sans confusion.

Answer 12

mon cas semble être un bug .... avec git 2.21.0

J'ai fait un pull ... il s'est plaint de fichiers binaires:

warning: Cannot merge binary files: <path>
Auto-merging <path>
CONFLICT (content): Merge conflict in <path>
Automatic merge failed; fix conflicts and then commit the result.

Ensuite, rien dans les réponses ne donne une sortie qui ait un sens.

Si je regarde quel fichier j'ai maintenant ... c'est celui que j'ai édité. Si je fais soit:

git checkout --theirs -- <path>
git checkout --ours -- <path>

Je reçois la sortie:

Updated 0 paths from the index

et j'ai toujours ma version du fichier. Si je m et puis checkout, Il dira 1 à la place, mais il me donne toujours ma version du fichier.

git mergetool dit

No files need merging

et le statut git dit

    All conflicts fixed but you are still merging.
    (use "git commit" to conclude merge)

Une option consiste à annuler le commit. ... mais je n'ai pas eu de chance et j'ai eu beaucoup de commits, et ce mauvais était le premier. Je ne veux pas perdre de temps à répéter cela.

pour résoudre cette folie:

Je viens de courir

git commit

qui perd la version distante et probablement un peu d’espace en stockant un fichier binaire supplémentaire ... puis

git checkout <commit where the remote version exists> <path>

qui me rend la version distante

a ensuite modifié à nouveau le fichier ... puis validé et activé, ce qui signifie probablement encore une perte de place avec une autre copie du fichier binaire.