Comment fusionner tous les fichiers manuellement dans Git?
Je veux fusionner tous les fichiers manuellement avec meld ou tout autre outil de diff, comment puis-je le faire avec Git?
Lorsque je lance git mergetool ça dit no files need merging. Je suppose donc que je ne peux le faire que si j'ai des conflits.
Il existe un moyen beaucoup plus simple:
git merge --no-commit merge_branch
Comme le dit l'homme:
Avec
--no-commiteffectuer la fusion mais faire semblant que la fusion a échoué et ne pas s'engager automatiquement, pour donner à l'utilisateur une chance d'inspecter et de peaufiner le résultat de la fusion avant de valider.
J'ai eu un scénario où:
git merge --no-commit merge_branch
vient de provoquer une avance rapide.
Si cela se produit, vous pouvez utiliser:
git merge --no-commit --no-ff merge_branch
et vous pourrez ensuite revoir vos modifications
Une question similaire est Comment empêcher une fusion automatique en utilisant git?
FractalSpace a donné une réponse qui me semble utile:
$ git checkout master
$ git difftool -t kdiff3 local-branch HEAD
L'idée est d'utiliser difftools au lieu d'outils de fusion automatique pour sélectionner manuellement ce dont vous avez besoin et créer de nouveaux fichiers.
Remarque, si vous insistez pour fusionner manuellement (peut-être pour une certaine classe de fichiers), vous pouvez toujours définir un pilote de fusion .
Vous avez un exemple concret dans " Git - comment forcer le conflit de fusion et la fusion manuelle sur le fichier sélectionné ".
De cette façon, votre script de pilote de fusion peut appeler n'importe quel outil de fusion que vous souhaitez.
Pour tous ceux qui sont venus ici et se demandent maintenant quelle est la différence entre la réponse de @ True en utilisant git difftool et les autres réponses qui utilisent git merge, voir Git mergetool vs difftool .
En bref, si vous avez configuré git pour utiliser un diff.tool comme kdiff3, meld ou vimdiff, vous pourrez fusionner manuellement différents fichiers à l'aide de l'outil diff lui-même, et la ligne de commande peut être simple:
git difftool other_branch
... cela vous permettra d'effectuer une fusion manuelle bidirectionnelle entre votre branche actuelle et other_branch (décrite comme $ LOCAL et $ REMOTE dans man git-config).
La manière "correcte" dont parlent les autres réponses serait de configurer git à la place, par exemple kdiff3 ou vimdiff comme votre merge.tool, et utilise:
git merge --no-commit --no-ff other_branch
git mergetool
... cette commande peut effectuer une fusion manuelle à N voies entre $ BASE, $ LOCAL et $ REMOTE, dans $ MERGED. Voir https://stackoverflow.com/a/2235841/1264797 pour un exemple de configuration de git. Vous n'avez pas besoin de configurer le mergetool.*.cmd entrée du tout si vous utilisez l'un des outils que git connaît déjà. (Meld ne peut afficher que trois volets, donc si vous utilisez meld avec les paramètres par défaut, vous ne verrez pas $ BASE.)
Quelqu'un pourrait intervenir pour me corriger, mais à part la capacité de fusion N-way, les deux méthodes semblent produire le même résultat. Ni difftool ni mergetool n'ajoute other_branch comme parent sur le nouveau commit, donc dans les deux cas, la fusion n'est pas évidente dans par exemple gitk et devrait être décrit (et remarqué plus tard) dans le message de validation.
Je choisis la stratégie la nôtre (elle existe aussi en tant que choix dans TortoiseGit), après avoir fait un diff manuel où vous avez apporté les modifications que vous vouliez manuellement.
De: https://git-scm.com/docs/merge-strategies
Le mécanisme de fusion (commandes git merge et git pull) permet de choisir les "stratégies de fusion" du backend avec l'option -s. Certaines stratégies peuvent également prendre leurs propres options, qui peuvent être passées en donnant des arguments -X pour git merge et/ou git pull.
nôtre
Cela résout n'importe quel nombre de têtes, mais l'arborescence résultante de la fusion est toujours celle de la tête de branche actuelle, ignorant efficacement tous les changements de toutes les autres branches. Il est destiné à remplacer l'ancien historique de développement des branches latérales. Notez que ceci est différent de l'option -Xours à la stratégie de fusion "récursive".
Ce que Bitbucket verra plus tard est cependant un mystère pour moi, il reconnaît le commit comme fusion mais ne parvient pas à fusionner la branche (ne résout pas une pull-request) - probablement le gourou de Bitbucket pourrait aider sur ce problème, je ne peux même pas vous en donner journaux/messages d'erreur car je n'ai pas cette visibilité - git/TortoiseGit ne se plaint pas du tout cependant.