Я хочу объединить все файлы вручную с помощью meld или любого другого инструмента diff, как я могу сделать это с помощью Git?
Когда я запустил git mergetool
он говорит no files need merging
. Поэтому я полагаю, что могу сделать это, только если у меня есть конфликты.
Как объединить все файлы вручную в Git?
Ответ 1
Почему вы хотите объединить вручную?
Если вы хотите применить выборочные изменения, попробуйте использовать инструмент сравнения между файлом в двух ветких, примените нужные изменения и затем скопируйте этот "объединенный" файл как обычно.
Ответ 2
Существует гораздо более простой способ:
git merge --no-commit merge_branch
Как говорит человек:
С
--no-commit
выполните слияние, но притворитесь, что слияние не выполнено и выполните не autocommit, чтобы дать пользователю возможность проверить и дальше настроить результат слияния до совершение.
Ответ 3
У меня был сценарий, в котором:
git merge --no-commit merge_branch
просто вызвал ускоренную перемотку вперед.
Если это произойдет, вы можете использовать:
git merge --no-commit --no-ff merge_branch
а затем вы сможете просмотреть свои изменения.
Ответ 4
Аналогичный вопрос Как предотвратить использование авторезиста с помощью git?
FractalSpace дал ответ, который я считаю полезным:
$ git checkout master
$ git difftool -t kdiff3 local-branch HEAD
Идея заключается в использовании difffools вместо автоматического слияния инструментов, чтобы вручную выбрать то, что вам нужно, и создать новые файлы.
Ответ 5
Обратите внимание, что если вы настаиваете на объединении вручную (возможно, для определенного класса файлов), вы все равно можете определить файл слияния.
У вас есть конкретный пример в Git - как принудительно слить конфликт слияния и ручной слияние на выбранном файле.
Таким образом, ваш драйвер слияния script может вызвать любой инструмент слияния, который вы хотите.
Ответ 6
Для тех, кто пришел сюда и сейчас интересуется разницей между ответом @True, использующим git difftool
и другими ответами, использующими git merge
, см. Git mergetool против difftool.
Короче говоря, если у вас есть git, настроенный на использование современного diff.tool
такого как kdiff3, meld или vimdiff, вы сможете вручную объединять разные файлы, используя сам инструмент diff, и командная строка может быть простой:
git difftool other_branch
... это позволит вам выполнить двустороннее слияние вручную между вашей текущей веткой и other_branch (в man git-config
называется $ LOCAL и $ REMOTE).
"Правильный" способ, который обсуждают другие ответы, состоит в том, чтобы вместо этого сконфигурировать git для использования, например, kdiff3 или vimdiff в качестве merge.tool
, и использовать:
git merge --no-commit --no-ff other_branch
git mergetool
... эта команда может выполнить N-way ручное слияние между $ BASE, $ LOCAL и $ REMOTE в $ MERGED. См. fooobar.com/questions/784/... для одного примера того, как настроить git. Вам вообще не нужно настраивать запись mergetool.*.cmd
если вы используете один из инструментов, о которых git уже знает. (Meld может отображать только три панели, поэтому если вы используете meld с настройками по умолчанию, вы не увидите $ BASE.)
Кто-то может вскочить, чтобы поправить меня, но кроме способности N-way merge, оба метода дают одинаковый результат. Ни difftool
ни mergetool
добавляют other_branch в качестве родителя для нового коммита, поэтому в обоих случаях слияние неочевидно, например, в gitk, и его нужно будет описать (и заметить позже) в сообщении коммита.
Ответ 7
Я выбираю нашу стратегию (она существует также как выбор в TortoiseGit), после выполнения ручного сравнения, в котором вы внесли необходимые изменения вручную.
От: https://git -s cm.com/docs/merge -s trategies
Механизм слияния (команды git merge и git pull) позволяет бэкэнду выбирать "стратегии слияния" с опцией -s. Некоторые стратегии также могут иметь свои собственные опции, которые можно передать, задав аргументы -X для git merge и/или git pull.
наш
Это разрешает любое количество заголовков, но результирующее дерево слияния всегда совпадает с деревом текущей ветки, что фактически игнорирует все изменения из всех других ветвей. Он предназначен для замены старой истории развития боковых веток. Обратите внимание, что это отличается от нашей опции -X и стратегии рекурсивного слияния.
Однако то, что Bitbucket видит позже, для меня загадка: он распознает коммит как слияние, но не может фактически слить ветку (не решает запрос на извлечение) - вероятно, гуру Bitbucket может помочь в этом вопросе, я даже не могу дать вам никакого логи/сообщения об ошибках, поскольку у меня нет такой видимости - git/TortoiseGit не жалуется вообще.