Подтвердить что ты не робот

Как объединить все файлы вручную в Git?

Я хочу объединить все файлы вручную с помощью meld или любого другого инструмента diff, как я могу сделать это с помощью Git?

Когда я запустил git mergetool он говорит no files need merging. Поэтому я полагаю, что могу сделать это, только если у меня есть конфликты.

4b9b3361

Ответ 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 не жалуется вообще.