Чи є варіант git-merge --dry-run?

Я зливаюся у віддалену гілку, яка може мати багато конфліктів. Як я можу визначити, чи будуть конфлікти чи ні?

Я не бачу нічого подібного в положення --dry-runON git-merge.

Як зазначалося раніше, передайте --no-commitпрапор, але щоб уникнути швидкої передачі вперед, також перейдіть --no-ffтак:

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

Щоб переглянути поетапні зміни:

$ git diff --cached

І ви можете скасувати злиття, навіть якщо це швидке злиття вперед:

$ git merge --abort

Мені просто довелося реалізувати метод, який автоматично знаходить конфлікти між сховищем та його віддаленим. Це рішення робить об'єднання в пам'яті, щоб не торкатися індексу, а також робочого дерева. Я думаю, що це найбезпечніший спосіб вирішити цю проблему. Ось як це працює:

1. Дістаньте пульт до вашого сховища. Наприклад: git fetch origin master
2. Виконати git merge-base: git merge-base FETCH_HEAD master
3. Запустити git merge-tree: git merge-tree mergebase master FETCH_HEAD( mergebase - це шістнадцятковий ідентифікатор, який друкується на попередньому кроці)

Тепер припустимо, що ви хочете об'єднати віддаленого майстра з місцевим майстром, але ви можете використовувати будь-які гілки. git merge-treeвиконає злиття в пам’яті та надрукує результат на стандартний вихід. Греп за візерунок <<або >>. Або ви можете роздрукувати вихід у файл і перевірити це. Якщо ви знайдете рядок, що починається з "змінено в обох", то, швидше за все, виникне конфлікт.

Моє просте рішення жорстокої сили:

1. Створіть відділення "попереднього майстра" (від майстра курсу)

2. Об’єднайте всі речі, які ви хочете зробити, з цим попереднім майстром.
   Тоді ви можете побачити, як відбулося злиття, не торкнувшись майстра.

3. • Об'єднайте попереднього майстра в головний АБО
   • Об’єднайте всі звільнені від гілки банери в майстер

У будь-якому разі я б дотримувався порад @ orange80.

Скасувати злиття з git настільки просто, що ви навіть не повинні турбуватися про сухий хід:

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

EDIT: Як зазначено у коментарях нижче, якщо у вас є зміни в робочому каталозі чи області постановки, ви, ймовірно, захочете їх приховати перед тим, як зробити вищезазначене (інакше вони зникнуть після git resetвищезазначеного)

Я зробив псевдонім для цього і працює як шарм, я роблю це:

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

Зараз я просто дзвоню

git mergetest <branchname>

Щоб з’ясувати, чи є конфлікти.

Просто відрізняйте поточну гілку від віддаленої гілки, це скаже вам, що буде змінюватися, коли ви будете робити потяг / злиття.

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

Для цього я використовую команду request-pull git. Це дозволяє вам бачити всі зміни, які відбудуться під час об'єднання, але нічого не роблячи у ваших локальних або віддалених сховищах .

Наприклад, уявіть, що ви хочете об'єднати гілку з назвою "особливість-х" у свою головну гілку

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параметр, ви також отримаєте повний текст виправлення, точно так само, якби ви робили git diff для кожного зміненого файлу.

Я здивований, поки ніхто не запропонував використовувати патчі.

Скажіть, що ви хочете перевірити злиття з 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:

--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+ років існування цього питання ніхто не запропонував цього, здавалося б, очевидного рішення.

Це може бути цікаво: З документації:

Якщо ви спробували злиття, яке призвело до складних конфліктів, і хочете почати все спочатку, ви можете відновити за допомогою git merge --abort .

Але ви також можете зробити це наївним (але повільним) способом:

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

(Примітка. Це не буде працювати лише з клонуванням до / tmp. Вам потрібна копія, щоб бути впевненим, що невідомі зміни не будуть конфліктувати).

Мені відомо, що це давнє запитання, але воно вперше з’являється в пошуку Google.

Git представив опцію --ff-only при злитті.

Від: 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

Я використовую журнал git, щоб побачити, що змінилося на функції функції з головного відділення

git log does_this_branch..contain_this_branch_changes

наприклад - щоб побачити, які комісії є у ​​гілці функцій, яка не була об'єднана в головний:

git log master..feature_branch

Якщо ви хочете перейти з B до A, тоді ви повинні переконатися, що журнал git B..A нічого не показує, тобто A не має нічого, що B не має. Але навіть якщо B..A має щось, ви все-таки зможете злитися без конфліктів, тому вищесказане свідчить про дві речі: що буде швидкий рух вперед, і, таким чином, конфлікту ви не отримаєте.

Моє рішення - злитися назад.

Замість того, щоб об’єднувати свою гілку у віддалену гілку "цільової", об'єднайте її у свою.

git checkout my-branch
git merge origin/target-branch

Ви побачите, чи є конфлікти, і можете планувати, як їх вирішити.

Після цього ви можете або перервати злиття за допомогою git merge --abort, або (якщо не було конфліктів і злиття не відбулося) повернутися до попередньої фіксації черезgit reset --hard HEAD~1

Зробіть тимчасову копію вашої робочої копії, потім зробіть її та розрізніть дві.