git-merge - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

git-merge - об'єднайте дві або більше історій розробки разом

СИНТАКСИС

мерзотник злиття [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[-s ] [-X ] [-S[ ]]
[--[no-]rerere-autoupdate] [-m ] [ ...]
мерзотник злиття ГОЛОВА ...
мерзотник злиття --перервати

ОПИС

Включає зміни з названих комітів (з часу, коли їхня історія розійшлася
поточна гілка) у поточну гілку. Цю команду використовує мерзотник тягнути до
включати зміни з іншого репозиторію та можна використовувати вручну для об’єднання змін із
одна гілка в іншу.

Припустимо, що існує така історія і поточна гілка є "головною":

A---B---C тема
/
D---E---F---G майстер

Тоді «git merge topic» відтворить зміни, внесені в гілку теми з моменту її розходження
від основного (тобто E) до його поточної фіксації (C) поверх основного та запишіть результат
у новому коміті разом із іменами двох батьківських комітів і повідомленням журналу від
користувач, який описує зміни.

A---B---C тема
/\
D---E---F---G---H майстер

Другий синтаксис ( ГОЛОВА ...) підтримується з історичних причин. Не використовувати
це з командного рядка або в нових сценаріях. Це те саме, що git merge -m
....

Третій синтаксис ("git merge --abort") можна запустити лише після того, як злиття призведе до
конфлікти. мерзотник злиття --перервати перерве процес злиття та спробує реконструювати
стан перед злиттям. Однак, якщо на момент початку злиття були незафіксовані зміни (і
особливо якщо ці зміни були додатково змінені після початку злиття), мерзотник злиття
--перервати у деяких випадках не зможе реконструювати оригінальні зміни (до злиття).
Тому:

попередження: Біг мерзотник злиття з нетривіальними незафіксованими змінами не рекомендується: while
можливо, це може залишити вас у стані, з якого важко вийти у випадку a
конфлікту.

ВАРІАНТИ

--здійснювати, --не-здійснювати
Виконайте злиття та зафіксуйте результат. Цю опцію можна використовувати для перевизначення
--без фіксації.

За допомогою --no-commit виконайте злиття, але зробіть вигляд, що злиття не вдалося, і не фіксуйте автоматично,
щоб дати користувачеві можливість попередньо перевірити та налаштувати результат злиття
вчинення.

--редагувати, -е, --не-редагувати
Викличте редактор перед здійсненням успішного механічного злиття для подальшого редагування
автоматично створене повідомлення про злиття, щоб користувач міг пояснити та обґрунтувати злиття. The
Опцію --no-edit можна використовувати для прийняття автоматично згенерованого повідомлення (загалом це
збентежений). Параметр --edit (або -e) все ще корисний, якщо ви надаєте чернетку
повідомлення з параметром -m у командному рядку та хочете відредагувати його в редакторі.

Старіші сценарії можуть залежати від історичної поведінки, коли користувач не дозволяв редагувати
повідомлення журналу злиття. Вони побачать відкритий редактор, коли запустять git merge. Зробити
легше налаштувати такі сценарії до оновленої поведінки, змінної середовища
GIT_MERGE_AUTOEDIT можна встановити на ні на початку.

--ff
Коли злиття розв’язується як швидке перемотування вперед, оновлюйте лише покажчик розгалуження, без
створення коміту злиття. Це поведінка за замовчуванням.

--ні-фф
Створіть фіксацію злиття, навіть якщо злиття розв’язується як швидке перемотування вперед. Це
поведінка за замовчуванням під час об’єднання анотованого (і, можливо, підписаного) тега.

--ff-лише
Відмовтеся від злиття та виходу з ненульовим статусом, якщо поточний HEAD вже не є
актуальні або злиття можна вирішити як швидке перемотування вперед.

--log[= ], --no-log
На додаток до імен гілок, заповніть повідомлення журналу однорядковими описами від
максимум фактичні коміти, які об’єднуються. Дивись також git-fmt-merge-msg(1).

За допомогою --no-log не перераховувати однорядкові описи фактичних комітів, які об’єднуються.

--stat, -n, --no-stat
Показати diffstat в кінці злиття. Diffstat також контролюється
параметр конфігурації merge.stat.

З -n або --no-stat не показувати diffstat в кінці злиття.

-- сквош, -- без кабачків
Створіть робоче дерево та стан індексу, як ніби відбулося справжнє злиття (за винятком
злиття інформації), але фактично не робите фіксацію, не переміщуйте ГОЛОВКУ або не записуйте
$GIT_DIR/MERGE_HEAD (щоб викликати наступну команду git commit для створення коміту злиття).
Це дозволяє вам створити один комміт поверх поточної гілки, ефектом якого є
те саме, що злиття іншої гілки (або більше у випадку восьминога).

За допомогою --no-squash виконайте злиття та зафіксуйте результат. Цю опцію можна використовувати для
перевизначити --squash.

-s , --стратегія=
Використовуйте задану стратегію злиття; можна надати більше одного разу, щоб вказати їх у
щоб їх судити. Якщо немає параметра -s, є вбудований список стратегій
замість нього використовується (мерзотник злиття-рекурсивний при об'єднанні однієї голови, мерзотник злиття-восьминіг
інакше).

-X , --strategy-option=
Передайте спеціальний параметр стратегії злиття до стратегії злиття.

--verify-signatures, --no-verify-signatures
Переконайтеся, що коміти, які об’єднуються, мають хороші та надійні підписи GPG, і припиніть роботу
злиття, якщо вони цього не роблять.

--резюме, --без підсумку
Синоніми до --stat і --no-stat; вони не підтримуються і будуть видалені в
майбутнє.

-q, -- тихо
Працювати тихо. Має на увазі відсутність прогресу.

-v, -- багатослівний
Будьте багатослівними.

--прогрес, --без прогресу
Явно ввімкніть/вимкніть прогрес. Якщо жоден не вказано, прогрес відображається, якщо
стандартна помилка підключена до терміналу. Зверніть увагу, що не всі стратегії злиття можуть
підтримка звітності про прогрес.

-S[ ], --gpg-sign[= ]
Підпишіть GPG отриманий комміт злиття. Аргумент keyid є необов’язковим і використовується за умовчанням
особу комітера; якщо вказано, його потрібно прикріпити до параметра без пробілу.

-м
Встановіть повідомлення коміту, яке буде використовуватися для коміту злиття (якщо його буде створено).

Якщо вказано --log, короткий журнал комітів, які об’єднуються, буде додано до
вказане повідомлення.

Команда мерзотник fmt-merge-msg Команда може бути використана для встановлення хорошого значення за замовчуванням для автоматизованого мерзотник
злиття заклики. Автоматизоване повідомлення може містити опис гілки.

--[no-]rerere-autoupdate
Дозволити механізму rerere оновлювати індекс із результатом автоматичного конфлікту
дозвіл, якщо це можливо.

--перервати
Перервіть поточний процес вирішення конфлікту та спробуйте реконструювати попереднє злиття
стан.

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

мерзотник злиття --перервати еквівалентна мерзотник скидання -- об'єднати коли присутній MERGE_HEAD.

...
Зобов’язує, як правило, інших керівників філій, об’єднатися з нашою філією. Вказуючи більше ніж
один комміт створить злиття з більш ніж двома батьками (люб’язно називають an
Восьминіг злиття).

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

Якщо вказано FETCH_HEAD (і жодного іншого коміту), гілки, записані в
Файл .git/FETCH_HEAD за допомогою попереднього виклику git fetch для злиття об’єднується до
поточна гілка.

ПОПЕРЕДНЄ ЗЛИВАННЯ ПРОВЕРКИ

Перш ніж застосовувати зовнішні зміни, ви повинні привести свою власну роботу в хорошу форму та віддано
локально, тому він не буде забитий у разі виникнення конфліктів. Дивись також git-stash(1). мерзотник
тягнути та мерзотник злиття зупиниться, не роблячи нічого, коли локальні незафіксовані зміни накладаються
з файлами, які мерзотник тягнути/мерзотник злиття може знадобитися оновлення.

Щоб уникнути запису непов’язаних змін у коміті злиття, мерзотник тягнути та мерзотник злиття буде також
перервати, якщо в індексі зареєстровано будь-які зміни щодо фіксації HEAD. (Один
винятком є ​​випадки, коли змінені записи індексу перебувають у стані, який був би результатом
вже об'єднати.)

Якщо всі названі коміти вже є предками HEAD, мерзотник злиття вийде рано з
повідомлення «Вже оновлено».

ШВИДКО ВПЕРЕД ВЕЛИКИЙ

Часто поточний керівник гілки є предком названого коміту. Це найпоширеніший
особливо при виклику з мерзотник тягнути: ви відстежуєте репозиторій вище за течією, ви
не вносили жодних локальних змін, і тепер ви хочете оновити до новішої попередньої версії.
У цьому випадку новий комміт не потрібен для збереження об’єднаної історії; натомість ГОЛОВА
(разом з індексом) оновлюється для вказівки на названий комміт без створення додаткового
злиття комітів.

Цю поведінку можна придушити за допомогою опції --no-ff.

ІСТИНА ВЕЛИКИЙ

За винятком швидкого злиття вперед (див. вище), гілки, які потрібно об’єднати, мають бути пов’язані
разом за допомогою коміту злиття, у якому вони обидва є батьками.

Об’єднана версія, що узгоджує зміни з усіх гілок, які потрібно об’єднати, фіксується, і
ваш HEAD, індекс і робоче дерево оновлюються до нього. Можливі модифікації
у робочому дереві, якщо вони не перекриваються; оновлення збереже їх.

Коли незрозуміло, як узгодити зміни, відбувається наступне:

1. Покажчик HEAD залишається незмінним.

2. Посилання MERGE_HEAD встановлено, щоб вказувати на голову іншої гілки.

3. Шляхи, які об’єднані чисто, оновлюються як у файлі індексу, так і у вашому робочому дереві.

4. Для конфліктуючих шляхів файл індексу записує до трьох версій: етап 1 зберігає
версія від спільного предка, етап 2 від HEAD і етап 3 від MERGE_HEAD (ви
можна перевірити етапи за допомогою git ls-files -u). Файли робочого дерева містять
результат роботи програми «злиття»; тобто результати тристороннього злиття зі знайомими маркерами конфлікту
<<< === >>>.

5. Ніяких інших змін не вноситься. Зокрема, локальні модифікації, які ви мали перед собою
розпочате злиття залишиться незмінним, а записи індексу для них залишаться такими, як були,
тобто відповідність HEAD.

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

ОБЛИВАННЯ TAG

Під час об’єднання анотованого (і, можливо, підписаного) тегу, Git завжди створює комміт злиття
навіть якщо швидке злиття вперед можливе, і шаблон повідомлення фіксації підготовлено з
повідомлення тегу. Крім того, якщо тег підписаний, перевірка підпису повідомляється як a
коментар у шаблоні повідомлення. Дивись також git-тег(1).

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

У такому випадку ви можете самостійно «розгорнути» тег перед подачею його в git merge або передати
--ff-тільки коли у вас немає ніякої роботи самостійно. напр

git вибірки походження
git merge v1.2.3^0
git merge --ff-only v1.2.3

ЯК КОНФЛІКТИ ЕСТЬ ПРЕДСТАВЛЕНО

Під час злиття файли робочого дерева оновлюються відповідно до результату злиття.
Серед змін, внесених у версію спільного предка, ті, що не перекриваються (тобто
ви змінили частину файлу, а інша сторона залишила цю область недоторканою, або навпаки)
включені в кінцевий результат дослівно. Коли обидві сторони внесли зміни в те саме
однак Git не може випадково вибрати одну сторону замість іншої, і просить вас вирішити
це, залишивши те, що обидві сторони зробили з цією територією.

За замовчуванням Git використовує той самий стиль, що й той, який використовує програма «злиття» з RCS
набір для представлення такого конфліктного шматка, як цей:

Ось рядки, які або незмінні від загальноприйнятих
предок, або чисто вирішено, тому що змінилася лише одна сторона.
<<<<<<< yours:sample.txt
Вирішувати конфлікти важко;
Ходімо за покупками.
=======
Git полегшує вирішення конфліктів.
>>>>>>> їхній: sample.txt
А ось ще один рядок, який чітко вирішено або не змінено.

Область, де сталася пара суперечливих змін, позначена маркерами <<<<<<<,
======= і >>>>>>>. Частина перед ======= зазвичай є вашою стороною та частиною
потім, як правило, на їхньому боці.

Формат за замовчуванням не показує те, що сказано в оригіналі в конфліктній області. ви
не можу сказати, скільки рядків було видалено та замінено зауваженням Барбі на вашому боці. The
єдине, що ви можете сказати, це те, що ваша сторона хоче сказати, що це важко, і ви віддаєте перевагу піти
робити покупки, тоді як інша сторона хоче стверджувати, що це легко.

Альтернативний стиль можна використовувати, встановивши конфігурацію "merge.conflictStyle".
змінна на "diff3". У стилі "diff3" наведений вище конфлікт може виглядати так:

Ось рядки, які або незмінні від загальноприйнятих
предок, або чисто вирішено, тому що змінилася лише одна сторона.
<<<<<<< yours:sample.txt
Вирішувати конфлікти важко;
Ходімо за покупками.
|||||||
Вирішувати конфлікти важко.
=======
Git полегшує вирішення конфліктів.
>>>>>>> їхній: sample.txt
А ось ще один рядок, який чітко вирішено або не змінено.

Крім <<<<<<<, ======= і >>>>>>>, він використовує ще один ||||||| маркер
після якого йде оригінальний текст. Ви можете сказати, що оригінал просто констатував факт,
і ваша сторона просто піддалася цій заяві та здалася, тоді як інша сторона намагалася це зробити
мати більш позитивне ставлення. Іноді ви можете знайти кращу роздільну здатність
перегляд оригіналу.

ЯК TO ВИРІШИТИ КОНФЛІКТИ

Побачивши конфлікт, ви можете зробити дві речі:

· Вирішити не об’єднуватися. Єдине очищення, яке вам потрібно, це скинути файл індексу до
HEAD зобов’язується відмінити 2. і очистити робоче дерево змін, внесених 2. і 3.; git
Для цього можна використати merge --abort.

· Вирішуйте конфлікти. Git позначатиме конфлікти в робочому дереві. Відредагуйте файли
у форму і мерзотник додавати їх до індексу. використання мерзотник commit для укладення угоди.

Ви можете вирішити конфлікт за допомогою кількох інструментів:

· Використовуйте інструмент злиття. git mergetool, щоб запустити графічний mergetool, який вам підійде
через злиття.

· Подивіться на відмінності. git diff покаже тристоронню різницю, підсвічуючи зміни з
як версії HEAD, так і MERGE_HEAD.

· Подивіться на відмінності кожної гілки. git log --merge -p спочатку покаже відмінності
для версії HEAD, а потім версії MERGE_HEAD.

· Подивіться на оригінали. git show :1:filename показує спільного предка, git show
:2:filename показує версію HEAD, а git show :3:filename показує MERGE_HEAD
версія.

ПРИКЛАДИ

· Об’єднайте виправлення та покращення гілок поверх поточної гілки, створюючи восьминога
злиття:

$ git merge виправляє покращення

· Об’єднайте застарілу гілку в поточну гілку, використовуючи нашу стратегію злиття:

$ git merge -s наш застарілий

· Об’єднайте maint гілки в поточну гілку, але не створюйте нового коміту
автоматично:

$ git merge --no-commit maint

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

Вам слід утримуватися від зловживання цією опцією для внесення суттєвих змін у злиття
здійснити. Невеликі виправлення, як-от зміна назви випуску/версії, будуть прийнятними.

ВЕЛИКИЙ СТРАТЕГІЇ

Механізм злиття (команди git merge та git pull) дозволяє бекенд злиття стратегії
вибрати з опцією -s. Деякі стратегії також можуть мати власні варіанти, які можуть бути
передано, даючи -X аргументи для git merge та/або git pull.

рішення
Це може дозволити лише дві головки (тобто поточну гілку та іншу гілку, яку ви витягли
from) за допомогою 3-стороннього алгоритму злиття. Він намагається ретельно виявити перехресне злиття
неоднозначності і вважається, як правило, безпечним і швидким.

рекурсивний
Це може дозволити лише дві головки за допомогою 3-стороннього алгоритму злиття. Коли є більше ніж
один загальний предок, який можна використовувати для 3-стороннього злиття, він створює об'єднане дерево
загальних предків і використовує це як опорне дерево для 3-стороннього злиття. Це має
Повідомлялося, що це призводить до меншої кількості конфліктів злиття, не викликаючи помилкового злиття тестами
зроблено на основі фактичних комітів злиття, взятих з історії розробки ядра Linux 2.6.
Крім того, це може виявляти та обробляти злиття, що включають перейменування. Це значення за замовчуванням
стратегія злиття при витягуванні або об'єднанні однієї гілки.

Команда рекурсивний стратегія може приймати такі варіанти:

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

Це не слід плутати з нести стратегія злиття, яка навіть не виглядає
на те, що інше дерево містить взагалі. Він відкидає все, що робило інше дерево,
декларування наші історія містить усе, що в ній відбувалося.

їх
Це протилежність нести.

терпіння
За допомогою цієї опції, злиття-рекурсивний витрачає трохи додаткового часу, щоб уникнути помилок
які іноді виникають через неважливі збігові рядки (наприклад, дужки від різних
функції). Використовуйте це, коли гілки, які потрібно об’єднати, сильно розходяться. Дивись також
git-diff(1) --терпіння.

diff-algorithm=[терпіння|мінімальна|гістограма|myers]
Розповідає злиття-рекурсивний використовувати інший алгоритм diff, який може допомогти уникнути
помилки злиття, які виникають через неважливі збігові лінії (наприклад, дужки від
різні функції). Дивись також git-diff(1) --диф-алгоритм.

ignore-space-change, ignore-all-space, ignore-space-at-eol
Обробляє рядки із зазначеним типом зміни пробілів незмінними для
заради тристороннього злиття. Зміни пробілів у поєднанні з іншими змінами рядка
не ігноруються. Дивись також git-diff(1) -b, -w та --ignore-space-at-eol.

· Якщо їх версія лише вносить зміни пробілів до рядка, наші версія є
використаний;

· Якщо наші версія вносить зміни пробілів, але їх версія включає а
істотна зміна, їх використовується версія;

· В іншому випадку злиття відбувається звичайним способом.

перенормувати
Це запускає віртуальну виписку та реєстрацію всіх трьох етапів файлу, коли
вирішення тристороннього злиття. Цей параметр призначений для використання при об’єднанні гілок
з різними чистими фільтрами або правилами нормалізації кінця рядка. Дивіться «Об’єднання
філії з різними атрибутами реєстрації/виписки». gitattributes(5) для
подробиці

без перенормування
Вимикає параметр перенормування. Це перевизначає merge.renormalize
змінна конфігурації.

rename-threshold=
Контролює поріг подібності, який використовується для виявлення перейменування. Дивись також git-diff(1)
-М.

піддерево[= ]
Цей варіант є більш розширеною формою піддерево стратегія, де стратегія робить
здогадка про те, як два дерева повинні бути зміщені, щоб збігатися один з одним під час злиття.
Натомість зазначений шлях має префікс (або видалений з самого початку), щоб зробити
форма двох дерев, щоб відповідати.

восьминіг
Це вирішує випадки з більш ніж двома головками, але відмовляється виконувати це комплексне злиття
потребує ручного вирішення. В першу чергу він призначений для використання для об’єднання тематичної гілки
голови разом. Це стратегія злиття за замовчуванням, коли витягується або об’єднується більше ніж
одна гілка.

нести
Це вирішує будь-яку кількість голів, але результуюче дерево злиття завжди є таким
поточного керівника філії, фактично ігноруючи всі зміни з усіх інших гілок.
Він призначений для того, щоб замінити стару історію розвитку бічних гілок. Примітка
що це відрізняється від параметра -Xours від параметра рекурсивний стратегія злиття.

піддерево
Це модифікована рекурсивна стратегія. При об’єднанні дерев A і B, якщо B відповідає
піддерево A, B спочатку коригується відповідно до деревоподібної структури A, а не
читання дерев на тому ж рівні. Це коригування також здійснюється для загального
дерево предків.

Зі стратегіями, які використовують тристороннє злиття (включаючи стандартне, рекурсивний), якщо зміни
зроблено на обох гілках, але пізніше буде повернено на одну з гілок, ця зміна буде
присутні в об’єднаному результаті; деякі люди вважають таку поведінку заплутаною. Це відбувається тому, що
при виконанні злиття враховуються лише головки та основа злиття, а не
індивідуальні зобов'язання. Таким чином, алгоритм злиття вважає повернену зміну ні
змінити взагалі, а замість цього замінює змінену версію.

КОНФІГУРАЦІЯ

merge.conflictStyle
Укажіть стиль, у якому конфліктні фрагменти записуються до файлів робочого дерева
злиття. Типовим значенням є «об’єднання», яке показує маркер конфлікту <<<<<<<, зміни внесені
одна сторона, маркер =======, зміни, внесені іншою стороною, а потім маркер >>>>>>>>.
Альтернативний стиль, "diff3", додає ||||||| маркер і оригінальний текст перед
======= маркер.

merge.defaultToUpstream
Якщо злиття викликається без будь-яких аргументів фіксації, об’єднує налаштовані вихідні гілки
для поточної гілки, використовуючи останні спостережувані значення, збережені в їх
дистанційне відстеження відділень. Значення гілки. .об'єднати це ім'я
гілки на віддаленому пристрої, названі за гілкою. .remote консультуються, і
потім вони відображаються за допомогою дистанційного керування. .fetch до відповідного дистанційного відстеження
гілки, а кінчики цих гілок відстеження об’єднані.

merge.ff
За замовчуванням Git не створює додаткового коміту злиття під час об’єднання коміту, який є a
нащадок поточного коміту. Натомість кінчик поточної гілки є
перемотування вперед. Якщо встановлено значення false, ця змінна повідомляє Git створити додаткове злиття
commit у такому випадку (еквівалентно наданню параметра --no-ff з командного рядка).
Якщо встановлено значення only, дозволено лише таке швидке злиття вперед (еквівалентно наданню
--ff-only параметр з командного рядка).

merge.branchdesc
На додаток до імен гілок, заповніть повідомлення журналу текстом опису гілки
пов'язані з ними. За замовчуванням false.

merge.log
На додаток до імен гілок, заповніть повідомлення журналу щонайбільше вказаним
кількість однорядкових описів із фактичних комітів, які об’єднуються.
За замовчуванням значення false, а true є синонімом 20.

merge.renameLimit
Кількість файлів, які слід враховувати під час визначення перейменування під час злиття; якщо
не вказано, за умовчанням використовується значення diff.renameLimit.

об'єднати.перенормувати
Повідомте Git, що канонічне представлення файлів у сховищі змінилося
час (наприклад, попередні фіксації текстових файлів із закінченнями рядків CRLF, але останні
використовуйте закінчення рядків LF). У такому сховищі Git може конвертувати дані, записані в
надає канонічної форми перед виконанням злиття, щоб зменшити непотрібні конфлікти.
Для отримання додаткової інформації дивіться розділ «Об’єднання відділень з різними реєстрацією/виїздом
атрибути» в gitattributes(5).

merge.stat
Чи слід друкувати параметр diffstat між ORIG_HEAD і результатом злиття в кінці
злиття. Правда за замовчуванням.

злиття.інструмент
Контролює, який інструмент злиття використовує git-mergetool(1). Список нижче показує дійсні
вбудовані значення. Будь-яке інше значення розглядається як спеціальний інструмент злиття та вимагає, щоб a
відповідний інструмент злиття. Визначено змінну .cmd.

· араксіс

· до н.е

· bc3

· код порівняння

· дельтоходець

· diffmerge

· дифузний

· виникати

· виникати

· gvimdiff

· gvimdiff2

· gvimdiff3

· kdiff3

· злити

· opendiff

· p4merge

· tkdiff

· черепаха

· vimdiff

· vimdiff2

· vimdiff3

· winmerge

· xxdiff

злиття.багатослівність
Керує обсягом виведення, що відображається стратегією рекурсивного злиття. Виходи рівня 0
нічого, крім останнього повідомлення про помилку, якщо було виявлено конфлікти. Лише вихідні дані рівня 1
конфлікти, 2 конфлікти виходів і зміни файлів. Рівень 5 і вище виводить налагодження
інформації. За замовчуванням — рівень 2. Може бути перевизначений за допомогою GIT_MERGE_VERBOSITY
змінна оточення

злиття. .name
Визначає зрозумілу людині назву для спеціального низькорівневого драйвера злиття. Побачити
gitattributes(5) для деталей.

злиття. .водій
Визначає команду, яка реалізує настроюваний низькорівневий драйвер злиття. Побачити
gitattributes(5) для деталей.

злиття. .рекурсивний
Назви низькорівневого драйвера злиття для використання під час виконання внутрішнього злиття між
спільних предків. Побачити gitattributes(5) для деталей.

відділення. .mergeOptions
Встановлює стандартні параметри для об’єднання у гілку . Синтаксис і підтримувані параметри
такі ж, як у мерзотник злиття, але значення параметрів містять пробіли
наразі не підтримуються.

Використовуйте git-merge онлайн за допомогою сервісів onworks.net