Есть ли опция git -merge -dry-run?

Ответ 1

Как отмечалось ранее, передайте флаг --no-commit, но, чтобы избежать фиксации ускоренной перемотки, также передайте --no-ff, например, так:

$ git merge --no-commit --no-ff $BRANCH

Для изучения поэтапных изменений:

$ git diff --cached

И вы можете отменить слияние, даже если это ускоренное слияние:

$ git merge --abort

Ответ 2

Мне просто пришлось реализовать метод, который автоматически находит конфликты между репозиторием и его удаленным. Это решение делает слияние в памяти, поэтому оно не будет касаться индекса или рабочего дерева. Я думаю, что это самый безопасный способ решить эту проблему. Вот как это работает:

• Извлеките пульт в ваш репозиторий. Например: git fetch origin master
• Запустить git слияние: git merge-base FETCH_HEAD master
• Запустить git merge-tree: git merge-tree mergebase master FETCH_HEAD (mergebase - это шестнадцатеричный идентификатор, который сбрасывается на предыдущем шаге)

Теперь предположим, что вы хотите объединить удаленный мастер с вашим локальным мастером, но вы можете использовать любые ветки. git merge-tree выполняет слияние в памяти и выводит результат на стандартный вывод. Grep для шаблона << или >>. Или вы можете распечатать вывод в файл и проверить это. Если вы найдете строку, начинающуюся с "измененной в обоих", то, скорее всего, будет конфликт.

Ответ 3

Мое простое решение проблемы грубой силы:

1. Создайте ветку "pre-master" (конечно же, от мастера)

2. Объедините все, что вы хотите, с этим предварительным мастером.
   Тогда вы сможете увидеть, как произошло слияние, не касаясь мастера.

3. • Объединить pre-master в master ИЛИ
   • Объедините все ветки, выпущенные подражателями, в мастера

В любом случае, я бы следовал совету @orange80.

Ответ 4

Отмена слияния с git настолько проста, что вы даже не должны беспокоиться о сухом прогоне:

$ git pull $REMOTE $BRANCH
# uh oh, that wasn't right
$ git reset --hard ORIG_HEAD
# all is right with the world

ИЗМЕНИТЬ: Как отмечено в комментариях ниже, если у вас есть изменения в рабочем каталоге или в рабочей области, вы, вероятно, захотите их спрятать, прежде чем делать это (иначе они исчезнут после git reset выше)

Ответ 5

Я сделал псевдоним для этого и работал как шарм, я делаю это:

 git config --global alias.mergetest '!f(){ git merge --no-commit --no-ff "$1"; git merge --abort; echo "Merge aborted"; };f '

Теперь я просто звоню

git mergetest <branchname>

Чтобы узнать, есть ли какие-либо конфликты.

Ответ 6

Просто сравните текущую ветку с удаленной ветвью, это скажет вам, что изменится, когда вы будете тянуть/слить.

#see diff between current master and remote branch
git diff master origin/master

Ответ 7

Я использую команду request-pull git, чтобы сделать это. Он позволяет видеть все изменения, которые произойдут при слиянии, , но ничего не делая на локальных или удаленных репозиториях.

Например, представьте, что вы хотите объединить ветвь с именем "feature-x" в вашу основную ветвь

git request-pull master origin feature-x

покажет вам, что произойдет (не делая ничего):

The following changes since commit fc01dde318:
    Layout updates (2015-06-25 11:00:47 +0200)
are available in the git repository at:
    http://fakeurl.com/myrepo.git/ feature-x
for you to fetch changes up to 841d3b41ad:
----------------------------------------------------------------
john (2):
    Adding some layout
    Refactoring
ioserver.js            |   8 +++---
package.json           |   7 +++++-
server.js              |   4 +--
layout/ldkdsd.js       | 277 +++++++++++++++++++++++++++++++++++++
4 files changed, 289 insertions(+), 7 deletions(-)
create mode 100644 layout/ldkdsd.js

Если вы добавите параметр -p, вы также получите полный текст патча, точно так же, как если бы вы выполняли diff git для каждого измененного файла.

Ответ 8

Я удивлен, что никто не предложил использовать исправления.

Предположим, вы хотите протестировать слияние с your_branch на master (я предполагаю, что вы выведете master):

$ git diff master your_branch > your_branch.patch
$ git apply --check your_branch.patch
$ rm your_branch.patch

Это должно сделать трюк.

Если вы получаете ошибки, например

error: patch failed: test.txt:1
error: test.txt: patch does not apply

Это означает, что патч не был успешным, и слияние создало бы конфликты. Отсутствие вывода означает, что патч чист, и вы сможете легко объединить ветвь

Обратите внимание, что это будет не, фактически изменит ваше рабочее дерево (помимо создания файла патча, конечно, но вы можете безопасно удалить его впоследствии). В документации git -apply:

--check
    Instead of applying the patch, see if the patch is applicable to the
    current working tree and/or the index file and detects errors. Turns
    off "apply".

Обратите внимание на любого, кто умнее/опытнее с git, чем я: пожалуйста, дайте мне знать, если я ошибаюсь здесь, и этот метод показывает другое поведение, чем регулярное слияние. Кажется странным, что в течение 8 + лет, когда этот вопрос существовал, никто не предложил бы это, казалось бы, очевидное решение.

Ответ 9

Это может быть интересно: из документации:

Если вы попытались слить, что привело к сложным конфликтам и начните, вы можете восстановить с помощью git merge -abort.

Но вы также можете сделать это наивным (но медленным) способом:

rm -Rf /tmp/repository
cp -r repository /tmp/
cd /tmp/repository
git merge ...
...if successful, do the real merge. :)

(Примечание. Он не будет работать с клонированием в /tmp, вам понадобится копия, чтобы быть уверенным, что незафиксированные изменения не будут конфликтовать).

Ответ 10

Я знаю, что это старый вопрос, но он первый появляется в поиске Google.

Git вводил параметр -ff только при слиянии.

От: http://git-scm.com/docs/git-merge

---

- и далее только

Откажитесь от слияния и выхода с ненулевым статусом, если текущая HEAD уже обновлена ​​или слияние может быть разрешено как ускоренная перемотка вперед.

Выполнение этого будет пытаться объединить и ускорить перемотку вперед, и если оно не сможет прерваться и предложит вам ускорить перемотку вперед, но не будет отключена ваша рабочая ветка. Если он может выполнить перемотку вперед, то он выполнит слияние на вашей рабочей ветке. Эта опция также доступна на git pull. Таким образом, вы можете сделать следующее:

git pull --ff-only origin branchA #See if you can pull down and merge branchA

git merge --ff-only branchA branchB #See if you can merge branchA into branchB

Ответ 11

Я использую журнал git, чтобы узнать, что изменилось в ветки функции из главной ветки

git log does_this_branch..contain_this_branch_changes

например. - посмотреть, какие коммиты находятся в ветки признаков, которая/не была объединена с мастером:

git log master..feature_branch

Ответ 12

Если вы хотите перемотка вперед от B до A, вы должны убедиться, что git log B..A ничего не показывает, то есть A не имеет ничего, что B не имеет. Но даже если у B..A есть что-то, вы все равно сможете слиться без конфликтов, поэтому приведенное выше показывает две вещи: что будет ускоренная перемотка вперед, и поэтому вы не столкнетесь с конфликтом.

Ответ 13

Сделайте временную копию вашей рабочей копии, затем объедините ее и разделите две.