Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.51.1 no changes
-
2.51.0
2025-08-18
- 2.50.1 no changes
-
2.50.0
2025-06-16
- 2.49.1 no changes
-
2.49.0
2025-03-14
- 2.47.1 → 2.48.2 no changes
-
2.47.0
2024-10-06
- 2.43.2 → 2.46.4 no changes
-
2.43.1
2024-02-09
-
2.43.0
2023-11-20
- 2.42.1 → 2.42.4 no changes
-
2.42.0
2023-08-21
- 2.39.4 → 2.41.3 no changes
-
2.39.3
2023-04-17
- 2.38.1 → 2.39.2 no changes
-
2.38.0
2022-10-02
- 2.35.1 → 2.37.7 no changes
-
2.35.0
2022-01-24
- 2.34.1 → 2.34.8 no changes
-
2.34.0
2021-11-15
- 2.33.2 → 2.33.8 no changes
-
2.33.1
2021-10-12
-
2.33.0
2021-08-16
- 2.30.1 → 2.32.7 no changes
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.27.1 → 2.28.1 no changes
-
2.27.0
2020-06-01
- 2.25.1 → 2.26.3 no changes
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 no changes
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.4 no changes
-
2.23.0
2019-08-16
- 2.22.2 → 2.22.5 no changes
-
2.22.1
2019-08-11
-
2.22.0
2019-06-07
- 2.20.1 → 2.21.4 no changes
-
2.20.0
2018-12-09
- 2.19.1 → 2.19.6 no changes
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 no changes
-
2.18.0
2018-06-21
- 2.17.1 → 2.17.6 no changes
-
2.17.0
2018-04-02
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
- 2.10.5 → 2.11.4 no changes
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
- 2.7.6 no changes
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
-
2.4.12
2017-05-05
- 2.3.10 no changes
-
2.2.3
2015-09-04
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
СИНОПСИС
gitmerge[-n] [--stat] [--compact-summary] [--no-commit] [--squash] [--[no-]edit] [--no-verify] [-s<strategy>] [-X<strategy-option>] [-S[<keyid>]] [--[no-]allow-unrelated-histories] [--[no-]rerere-autoupdate] [-m<msg>] [-F<file>] [--into-name<branch>] [<commit>…]gitmerge(--continue|--abort|--quit)
ОПИС
Включає зміни з іменованих комітів (з моменту, коли їхня історія розійшлася з поточної гілки) до поточної гілки. Ця команда використовується командою git pull для включення змін з іншого репозиторію та може бути використана вручну для об’єднання змін з однієї гілки в іншу.
Припустимо, що існує наступна історія, а поточна гілка є master:
A---B---C topic
/
D---E---F---G master
Потім git merge topic відтворить зміни, внесені до гілки topic з моменту її відхилення від master (тобто E), доки її поточний коміт (C) не буде розміщено поверх master, та запише результат у новий коміт разом з іменами двох батьківських комітів та повідомленням журналу від користувача, що описує зміни. Перед операцією ORIG_HEAD встановлюється на кінчик поточної гілки (G).
A---B---C topic
/ \
D---E---F---G---H master
Злиття зупиняється, якщо виникає конфлікт, який неможливо вирішити автоматично, або якщо під час ініціювання злиття було вказано параметр --no-commit. У цей момент ви можете виконати git merge --abort або git merge --continue.
git merge --abort перерве процес злиття та спробує відновити стан до злиття. Однак, якщо на початку злиття були незафіксовані зміни (і особливо якщо ці зміни були додатково змінені після початку злиття), git merge --abort у деяких випадках не зможе відновити оригінальні (до злиття) зміни. Тому:
|
Warning
|
Запуск git merge з нетривіальними незакоміченими змінами не рекомендується: хоча це можливо, це може призвести до стану, з якого буде важко вийти у разі конфлікту.
|
ОПЦІЇ
-
--commit -
--no-commit -
Виконайте об’єднання та зафіксуйте результат. Цей параметр можна використовувати для перевизначення
--no-commit.За допомогою параметра
--no-commitвиконайте злиття та зупиніть його безпосередньо перед створенням коміту злиття, щоб дати користувачеві можливість перевірити та додатково налаштувати результат злиття перед комітом.Зверніть увагу, що оновлення вперед не створюють коміту злиття, і тому немає способу зупинити ці злиття за допомогою
--no-commit. Таким чином, якщо ви хочете переконатися, що ваша гілка не буде змінена або оновлена командою merge, використовуйте--no-ffз--no-commit. -
--edit -
-e -
--no-edit -
Перед успішним механічним злиттям викличте редактор для подальшого редагування автоматично згенерованого повідомлення про злиття, щоб користувач міг пояснити та обґрунтувати злиття. Для прийняття автоматично згенерованого повідомлення можна використовувати параметр
--no-edit(зазвичай це не рекомендується). Опція--edit(або-e) все ще корисна, якщо ви надсилаєте чернетку повідомлення з опцією-mз командного рядка та хочете редагувати його в редакторі.Старіші скрипти можуть залежати від історичної поведінки, яка забороняла користувачеві редагувати повідомлення журналу злиття. Вони побачать відкритий редактор під час запуску
gitmerge. Щоб полегшити налаштування таких скриптів відповідно до оновленої поведінки, змінну середовищаGIT_MERGE_AUTOEDITможна встановити наnoна початку їх. -
--cleanup=<режим> -
Цей параметр визначає, як повідомлення злиття буде очищено перед комітом. Див. git-commit[1] для отримання додаткової інформації. Крім того, якщо <mode> має значення
scissors, scissors буде додано доMERGE_MSGперед передачею до механізму коміту у разі конфлікту злиття. -
--ff -
--no-ff -
--ff-only -
Визначає, як обробляється злиття, коли об’єднана історія вже є нащадком поточної історії.
--ffє значенням за замовчуванням, якщо не об’єднується анотований (і, можливо, підписаний) тег, який не зберігається у своєму природному місці в ієрархіїrefs/tags/, у цьому випадку передбачається--no-ff.За допомогою параметра
--ff, коли можливо, виконувати злиття як перемотування вперед (оновлювати лише вказівник гілки, щоб він відповідав об’єднаній гілці; не створювати коміт злиття). Якщо неможливо (коли історія об’єднання не є нащадком поточної історії), створювати коміт злиття.З опцією
--no-ffстворюється коміт злиття у всіх випадках, навіть якщо злиття можна було б виконати як перемотування вперед.З опцією
--ff-only, за можливості, виконувати злиття як перемотування вперед. Якщо це неможливо, відмовитися від злиття та завершити роботу з ненульовим статусом. -
-S[<key-id>] -
--gpg-sign[=<key-id>] -
--no-gpg-sign -
Підписує результуючий коміт злиття GPG. Аргумент <key-id> є необов’язковим і за замовчуванням використовує ідентифікатор комітера; якщо його вказано, він має бути прив’язаний до опції без пробілу.
--no-gpg-signкорисний для скасування як змінної конфігураціїcommit.gpgSign, так і попередньої змінної--gpg-sign. -
--log[=<n>] -
--no-log -
Окрім назв гілок, заповніть повідомлення журналу однорядковими описами максимум з <n> фактичних комітів, що об’єднуються. Див. також git-fmt-merge-msg[1].
З опцією
--no-logне виводьте однорядкові описи з фактичних комітів, що об’єднуються. -
--signoff -
--no-signoff -
Додайте трейлер «Підписано» коміттером в кінці повідомлення журналу комітів. Значення підпису залежить від проекту, в який ви робите коміт. Наприклад, він може засвідчувати, що коміттер має права надсилати роботу за ліцензією проекту або погоджується на певні заяви учасників, такі як Сертифікат походження розробника. (Див. https://developercertificate.org для отримання інформації про той, що використовується проектами ядра Linux та Git.) Зверніться до документації або керівництва проекту, в який ви робите внесок, щоб зрозуміти, як підписи використовуються в цьому проекті.
Опцію
--no-signoffможна використовувати для скасування попередньої опції--signoffу командному рядку.
-
--stat -
-n -
--no-stat -
Показати diffstat в кінці злиття. diffstat також контролюється параметром конфігурації merge.stat.
З опціями
-nабо--no-statне відображати статистику змін (diffstat) в кінці злиття. -
--compact-summary -
Показати компактний зведений опис в кінці злиття.
-
--squash -
--no-squash -
Створіть робоче дерево та стан індексу так, ніби відбулося справжнє злиття (за винятком інформації про злиття), але фактично не створюйте коміт, не переміщуйте
HEADта не записуйте$GIT_DIR/MERGE_HEAD(щоб наступна командаgitcommitстворила коміт злиття). Це дозволяє створити один коміт поверх поточної гілки, ефект якого такий самий, як і злиття іншої гілки (або кількох у випадку octopus).За допомогою
--no-squashвиконати злиття та зафіксувати результат. Цей параметр можна використовувати для перевизначення--squash.З
--squash,--commitне дозволено і призведе до невдачі. -
--[no-]verify -
За замовчуванням виконуються перехоплювачі pre-merge та commit-msg. Коли задано
--no-verify, вони ігноруються. Див. також githooks[5]. -
-s<стратегія> -
--strategy=<стратегія> -
Використовуйте задану стратегію злиття; можна вказати більше одного разу, щоб вказати їх у порядку, в якому їх слід спробувати. Якщо немає опції
-s, замість неї використовується вбудований список стратегій (ortпід час злиття однієї голови,octopusв іншому випадку). -
-X<option> -
--strategy-option=<option> -
Передати специфічний для стратегії злиття параметр до стратегії злиття.
-
--verify-signatures -
--no-verify-signatures -
Перевірте, чи коміт tip бічної гілки, що об’єднується, підписаний дійсним ключем, тобто ключем з дійсним UID: у моделі довіри за замовчуванням це означає, що ключ підпису був підписаний довіреним ключем. Якщо коміт tip бічної гілки не підписаний дійсним ключем, злиття переривається.
-
--summary -
--no-summary -
Синоніми до
--statта--no-stat; вони застарілі та будуть видалені в майбутньому. -
-q -
--quiet -
Працюйте тихо. Мається на увазі
--no-progress. -
-v -
--verbose -
Будьте багатослівними.
-
--progress -
--no-progress -
Явне ввімкнення/вимкнення функції «Прогрес». Якщо нічого не вказано, прогрес відображається, якщо стандартна помилка підключена до терміналу. Зверніть увагу, що не всі стратегії злиття можуть підтримувати звітування про прогрес.
-
--autostash -
--no-autostash -
Автоматично створіть тимчасовий запис stash перед початком операції, запишіть його в посилання
MERGE_AUTOSTASHта застосуйте його після завершення операції. Це означає, що ви можете виконати операцію на непрацюючому робочому дереві. Однак використовуйте обережно: остаточне застосування stash після успішного злиття може призвести до нетривіальних конфліктів. -
За замовчуванням команда
gitmergeвідмовляється об’єднувати історії, які не мають спільного предка. Цей параметр можна використовувати для ігнорування цього захисту під час об’єднання історій двох проектів, які розпочали своє життя незалежно. Оскільки це трапляється дуже рідко, змінної конфігурації, яка б увімкнула це за замовчуванням, не існує та не буде додано.
-
-m<msg> -
Встановіть повідомлення коміту, яке буде використовуватися для коміту злиття (якщо такий створено).
Якщо вказано
--log, до вказаного повідомлення буде додано короткий журнал комітів, що об’єднуються.Команду
gitfmt-merge-msgможна використовувати для встановлення гарного значення за замовчуванням для автоматичних викликівgitmerge. Автоматизоване повідомлення може містити опис гілки. -
--into-name<branch> -
Підготувати повідомлення про злиття за замовчуванням так, ніби злиття виконується з гілкою <гілка>, замість назви реальної гілки, з якою виконується злиття.
-
-F<файл> -
--file=<файл> -
Прочитайте повідомлення коміту, яке буде використано для коміту злиття (якщо такий створено).
Якщо вказано
--log, до вказаного повідомлення буде додано короткий журнал комітів, що об’єднуються. -
--rerere-autoupdate -
--no-rerere-autoupdate -
Після того, як механізм rerere повторно використає записане вирішення поточного конфлікту для оновлення файлів у робочому дереві, дозвольте йому також оновити індекс результатом вирішення.
--no-rerere-autoupdate— це гарний спосіб перевірити, що зробивrerere, та виявити потенційні помилки злиття, перш ніж занести результат до індексу за допомогою окремогоgitadd.
-
--overwrite-ignore -
--no-overwrite-ignore -
Тихо перезаписувати ігноровані файли з результату об’єднання. Це поведінка за замовчуванням. Використовуйте
--no-overwrite-ignoreдля переривання. -
--abort -
Перервати поточний процес вирішення конфліктів та спробувати відновити стан до об’єднання. Якщо запис автосховища присутній, застосувати його до робочого дерева.
Якщо на початку злиття були присутні незафіксовані зміни в робочому дереві,
gitmerge--abortу деяких випадках не зможе їх реконструювати. Тому рекомендується завжди зафіксувати або зберегти зміни перед запускомgitmerge.gitmerge--abortеквівалентноgitreset--merge, коли присутнійMERGE_HEAD, окрім випадків, коли також присутнійMERGE_AUTOSTASH, у цьому випадкуgitmerge--abortзастосовує запис stash до робочого дерева, тоді якgitreset--mergeзбереже збережені зміни у списку stash. -
--quit -
Забудьте про поточне злиття, що виконується. Залиште індекс та робоче дерево як є. Якщо присутній
MERGE_AUTOSTASH, запис stash буде збережено до списку stash. -
--continue -
Після того, як
gitmergeзупиниться через конфлікти, ви можете завершити злиття, виконавшиgitmerge--continue(див. розділ "ЯК ВИРІШИТИ КОНФЛІКТИ" нижче). - <commit>...
-
Коміти, зазвичай інші заголовки гілок, для злиття з нашою гілкою. Вказівка більше одного коміту створить злиття з більш ніж двома батьківськими елементами (ласково називається злиттям Octopus).
Якщо з командного рядка не надано жодного коміту, об’єднайте гілки віддаленого відстеження, які поточна гілка налаштована використовувати як свою початкову. Дивіться також розділ налаштування цієї сторінки підручника.
Коли вказано
FETCH_HEAD(і жодного іншого коміту), гілки, записані у файлі.git/FETCH_HEADпопереднім викликомgitfetchдля об’єднання, об’єднуються з поточною гілкою.
ПЕРЕВІРКИ ПЕРЕД ЗЛИТТЯМ
Перш ніж застосовувати зовнішні зміни, вам слід привести власну роботу у належний стан та закомітити її локально, щоб вона не була знищена у разі конфліктів. Див. також git-stash[1]. git pull та git merge зупиняться без жодних дій, коли локальні незакомічені зміни перетинаються з файлами, які git pull/git merge може потребувати оновлення.
Щоб уникнути запису непов’язаних змін у коміті злиття, git pull та git merge також перервуть виконання, якщо в індексі відносно коміту HEAD будуть зареєстровані будь-які зміни. (Можуть існувати спеціальні вузькі винятки з цього правила залежно від того, яка стратегія злиття використовується, але загалом індекс має відповідати HEAD.)
Якщо всі іменовані коміти вже є предками HEAD, git merge завершить роботу раніше терміну з повідомленням "Вже оновлено".
ШВИДКЕ ЗЛИТТЯ
Часто поточна гілка head є предком іменованого коміту. Це найпоширеніший випадок, особливо коли викликається з git pull: ви відстежуєте репозиторій основної ланки, не закомітили жодних локальних змін, а тепер хочете оновити його до новішої версії основної ланки. У цьому випадку новий коміт не потрібен для зберігання об’єднаної історії; натомість HEAD (разом з індексом) оновлюється, щоб вказувати на іменований коміт, без створення додаткового коміту злиття.
Цю поведінку можна придушити за допомогою опції --no-ff.
СПРАВЖНЄ ЗЛИТТЯ
За винятком випадків швидкого злиття (див. вище), гілки, що об’єднуються, повинні бути пов’язані разом комітом злиття, в якому обидві гілки є їхніми батьками.
Об’єднана версія, що узгоджує зміни з усіх гілок, що об’єднуються, зберігається, і ваші HEAD, індекс та робоче дерево оновлюються відповідно до неї. Ви можете мати зміни в робочому дереві, якщо вони не перетинаються; оновлення їх збереже.
Коли незрозуміло, як узгодити зміни, відбувається таке:
-
Вказівник
HEADзалишається незмінним. -
Посилання
MERGE_HEADвстановлено так, щоб воно вказувало на заголовок іншої гілки. -
Шляхи, які було об’єднано без зайвих зусиль, оновлюються як у файлі індексу, так і у вашому робочому дереві.
-
Для конфліктуючих шляхів індексний файл записує до трьох версій: етап 1 зберігає версію від спільного предка, етап 2 з
HEAD, а етап 3 зMERGE_HEAD(ви можете перевірити етапи за допомогоюgitls-files-u). Робочі файли дерева містять результат операції злиття, тобто результати 3-стороннього злиття зі знайомими маркерами конфлікту <<<===>>>. -
Записується посилання з назвою
AUTO_MERGE, яке вказує на дерево, що відповідає поточному вмісту робочого дерева (включаючи маркери конфліктів для текстових конфліктів). Зверніть увагу, що це посилання записується лише тоді, коли використовується стратегія злиттяort(за замовчуванням). -
Жодних інших змін не вноситься. Зокрема, локальні зміни, які ви мали до початку злиття, залишаться незмінними, а записи індексу для них залишаться такими, якими вони були, тобто збігатимуться з
HEAD.
Якщо ви спробували злиття, яке призвело до складних конфліктів, і хочете почати спочатку, ви можете відновити його за допомогою git merge --abort.
ТЕГ ОБ’ЄДНАННЯ
Під час об’єднання анотованого (і, можливо, підписаного) тегу, Git завжди створює коміт злиття, навіть якщо можливе прискорене злиття, а шаблон повідомлення коміта готується разом із повідомленням тегу. Крім того, якщо тег підписаний, перевірка підпису повідомляється як коментар у шаблоні повідомлення. Див. також git-tag[1].
Коли ви хочете просто інтегруватися з роботою, що веде до коміту, який випадково позначено тегом, наприклад, синхронізуючи з точкою випуску основної версії, ви можете не захотіти створювати непотрібний коміт злиття.
У такому випадку ви можете самостійно "розгорнути" тег перед тим, як передати його до git merge, або передати --ff-only, коли у вас немає власної роботи. Наприклад.
git fetch origin git merge v1.2.3^0 git merge --ff-only v1.2.3
ЯК ПРЕДСТАВЛЯЮТЬСЯ КОНФЛІКТИ
Під час злиття файли робочого дерева оновлюються, щоб відобразити результат злиття. Серед змін, внесених до версії спільного предка, ті, що не перекриваються (тобто ви змінили область файлу, а інша сторона залишила цю область недоторканою, або навпаки), дослівно включаються до кінцевого результату. Однак, коли обидві сторони внесли зміни в одну й ту саму область, Git не може випадковим чином вибрати одну сторону замість іншої та просить вас вирішити це, залишивши те, що обидві сторони зробили, в цій області.
За замовчуванням Git використовує той самий стиль, що й програма "merge" з набору RCS, для представлення такого конфліктного фрагмента, ось так:
Ось рядки, які або не змінилися від спільного предка, або чисто вирішені, оскільки змінилася лише одна сторона, або чисто вирішені, оскільки обидві сторони змінилися однаково. <<<<<<< ваш:sample.txt Вирішення конфліктів складне; Давайте підемо за покупками. ======= Git спрощує вирішення конфліктів. >>>>>>> їхній:sample.txt А ось ще один рядок, який чисто вирішено або не змінено.
Область, де відбулася пара конфліктуючих змін, позначена маркерами <<<<<<<, ======= та >>>>>>>. Частина перед ======= зазвичай відповідає вашій стороні, а частина після неї — їхній стороні.
Формат за замовчуванням не відображає, що було написано в оригіналі в конфліктній області. Ви не можете сказати, скільки рядків видалено та замінено зауваженням Барбі з вашого боку. Єдине, що ви можете сказати, це те, що ваша сторона хоче сказати, що це важко, і ви б воліли піти на шопінг, тоді як інша сторона хоче стверджувати, що це легко.
Альтернативний стиль можна використовувати, встановивши змінну конфігурації merge.conflictStyle на diff3 або zdiff3. У стилі diff3 вищезгаданий конфлікт може виглядати так:
Ось рядки, які або не змінилися від спільного предка, або чисто вирішені, оскільки змінилася лише одна сторона, <<<<<<< yours:sample.txt або чисто вирішені, оскільки обидві сторони змінилися однаково. Вирішення конфліктів складне; давайте підемо за покупками. ||||||| base:sample.txt або чисто вирішені, оскільки обидві сторони змінилися однаково. Вирішення конфліктів складне. ======= або чисто вирішені, оскільки обидві сторони змінилися однаково. Git спрощує вирішення конфліктів. >>>>>>> theirs:sample.txt А ось ще один рядок, який чисто вирішений або незмінений.
у стилі zdiff3 це може виглядати так:
Ось рядки, які або не змінилися від спільного предка, або чисто вирішені, оскільки змінилася лише одна сторона, або чисто вирішені, оскільки обидві сторони змінилися однаково. <<<<<<< yours:sample.txt Вирішення конфліктів складне; давайте підемо за покупками. ||||||| base:sample.txt або чисто вирішені, оскільки обидві сторони змінилися однаково. Вирішення конфліктів складне. ======= Git спрощує вирішення конфліктів. >>>>>>> theirs:sample.txt А ось ще один рядок, який чисто вирішений або незмінений.
Окрім маркерів <<<<<<<, ======= та >>>>>>>, використовується ще один маркер ||||||||, за яким йде оригінальний текст. Ви можете зрозуміти, що в оригіналі просто було сказано факт, а ваша сторона просто погодилася з цим твердженням і здалася, тоді як інша сторона намагалася мати більш позитивний настрій. Іноді ви можете знайти краще рішення, переглянувши оригінал.
ЯК ВИРІШУВАТИ КОНФЛІКТИ
Після виявлення конфлікту ви можете зробити дві речі:
-
Вирішіть не зливати. Єдине, що вам потрібно зробити, це скинути індексний файл до коміту
HEADдля скасування коміту 2 та очистити зміни робочого дерева, внесені комітами 2 та 3; для цього можна використовуватиgitmerge--abort. -
Вирішіть конфлікти. Git позначить конфлікти в робочому дереві. Відредагуйте файли у відповідній формі та
gitaddдодайте їх до індексу. Використовуйтеgitcommitабоgitmerge--continueдля завершення угоди. Остання команда перевіряє, чи виконується (перерване) злиття, перш ніж викликатиgitcommit.
Ви можете вирішити конфлікт за допомогою кількох інструментів:
-
Використайте mergetool.
gitmergetoolдля запуску графічного mergetool, який працюватиме разом з вами під час злиття. -
Перегляньте різниці.
gitdiffпокаже тристоронню різницю, виділяючи зміни з обох версій,HEADтаMERGE_HEAD.gitdiffAUTO_MERGEпокаже, які зміни ви внесли на даний момент для вирішення текстових конфліктів. -
Перегляньте відмінності з кожної гілки.
gitlog--merge-p<шлях> спочатку покаже відмінності для версіїHEAD, а потім для версіїMERGE_HEAD. -
Подивіться на оригінали.
gitshow:1:filenameпоказує спільного предка,gitshow:2:filenameпоказує версіюHEAD, аgitshow:3:filenameпоказує версіюMERGE_HEAD.
ПРИКЛАДИ
-
Об’єднати гілки виправлення та покращення поверх поточної гілки, створивши злиття типу "осьминог":
$ git merge fixes enhancements
-
Об’єднати гілку
obsoleteз поточною гілкою, використовуючи стратегію злиттяours:$ git merge -s ours obsolete
-
Об’єднати гілку
maintз поточною гілкою, але не створювати новий коміт автоматично:$ git merge --no-commit maint
Це можна використовувати, коли ви хочете включити подальші зміни до злиття або хочете написати власне повідомлення коміту злиття.
Вам слід утримуватися від зловживання цією опцією для внесення суттєвих змін у коміт злиття. Невеликі виправлення, такі як зміна назви релізу/версії, будуть прийнятними.
СТРАТЕГІЇ ЗЛИТТЯ
Механізм злиття (команди git merge та git pull) дозволяє вибирати бекенд-«стратегії злиття» за допомогою опції -s. Деякі стратегії також можуть приймати власні опції, які можна передати, надаючи аргументи -X<опція> командам git merge та/або git pull.
-
ort -
Це стратегія злиття за замовчуванням під час витягування або об’єднання однієї гілки. Ця стратегія може вирішити лише дві гілки за допомогою 3-стороннього алгоритму злиття. Коли є більше одного спільного предка, якого можна використовувати для 3-стороннього злиття, створюється об’єднане дерево спільних предків і використовується його як опорне дерево для 3-стороннього злиття. Повідомлялося, що це призводить до меншої кількості конфліктів злиття без виникнення помилок злиття, згідно з тестами, проведеними на фактичних коммітах злиття, взятих з історії розробки ядра Linux 2.6. Крім того, ця стратегія може виявляти та обробляти злиття, що включають перейменування. Вона не використовує виявлені копії. Назва цього алгоритму є абревіатурою ("Ostensibly Recursive’s Twin") і походить від того факту, що він був написаний як заміна попереднього алгоритму за замовчуванням,
recursive.У випадку, коли шлях є підмодулем, якщо коміт підмодуля, використаний на одному боці злиття, є нащадком коміту підмодуля, використаного на іншому боці злиття, Git намагається перейти до нащадка. В іншому випадку Git розглядатиме цей випадок як конфлікт, пропонуючи як вирішення коміт підмодуля, який є нащадком конфліктуючих, якщо такий існує.
Стратегія
ortможе приймати такі варіанти:-
ours -
Ця опція примусово автоматично вирішує конфліктуючі фрагменти, надаючи перевагу «нашій» версії. Зміни з іншого дерева, які не конфліктують з нашою стороною, відображаються в результаті злиття. Для бінарного файлу весь вміст береться з нашої сторони.
Це не слід плутати зі стратегією злиття
ours, яка навіть не дивиться на те, що містить інше дерево. Вона відкидає все, що зробило інше дерево, оголошуючи, що історіяourмістить усе, що в ній сталося. -
theirs -
Це протилежність до «ours»; зверніть увагу, що на відміну від «ours», немає стратегії злиття «hirs», з якою можна було б сплутати цей варіант злиття.
-
ignore-space-change -
ignore-all-space -
ignore-space-at-eol -
ignore-cr-at-eol -
Обробляє рядки з вказаним типом зміни пробілів як незмінні для тристороннього об’єднання. Зміни пробілів, змішані з іншими змінами в рядку, не ігноруються. Див. також git-diff[1]
-b,-w,--ignore-space-at-eolта--ignore-cr-at-eol.-
Якщо «їхня» версія вносить лише зміни пробілами в рядок, використовується «наша» версія;
-
Якщо «наша» версія містить зміни пробілів, але «їхня» версія містить суттєві зміни, використовується «їхня» версія;
-
В іншому випадку об’єднання відбувається у звичайному порядку.
-
-
renormalize -
Це запускає віртуальне отримання та повернення всіх трьох етапів будь-якого файлу, який потребує тристороннього злиття. Цей параметр призначений для використання під час об’єднання гілок з різними фільтрами очищення або правилами нормалізації кінця рядка. Див. "Об’єднання гілок з різними атрибутами реєстрації/вивантаження" в gitattributes[5] для отримання детальної інформації.
-
no-renormalize -
Вимикає опцію
renormalize. Це замінює змінну конфігураціїmerge.renormalize. -
find-renames[=<n>] -
Увімкнути виявлення перейменування, за потреби встановити поріг подібності. Це значення за замовчуванням. Це перевизначає змінну конфігурації
merge.renames. Див. також git-diff[1]--find-renames. -
rename-threshold=<n> -
Застарілий синонім до
find-renames=<n>. -
no-renames -
Вимкніть виявлення перейменування. Це замінює змінну конфігурації
merge.renames. Див. також git-diff[1]--no-renames. -
histogram -
Застарілий синонім до
diff-algorithm=histogram. -
patience -
Застарілий синонім до
diff-algorithm=patience. -
diff-algorithm=(histogram|minimal|myers|patience) -
Використовуйте інший алгоритм порівняння під час об’єднання, що може допомогти уникнути неправильних злиття, що виникають через неважливі збіги рядків (наприклад, фігурні дужки з різних функцій). Див. також git-diff[1]
--diff-algorithm. Зверніть увагу, щоortза замовчуванням має значенняdiff-algorithm=histogram, тоді як звичайні порівняння наразі за замовчуванням використовують налаштування конфігураціїdiff.algorithm. -
subtree[=<path>] -
Цей варіант є більш просунутою формою стратегії «піддерева», де стратегія робить припущення щодо того, як два дерева мають бути зміщені, щоб збігатися під час об’єднання. Натомість, зазначений шлях додається до початку (або видаляється з самого початку), щоб форма двох дерев збігалася.
-
-
recursive -
Тепер це синонім до
ort. Це була альтернативна реалізація до версії 2.49.0, але була перенаправлена наortу версії 2.50.0. Попередня рекурсивна стратегія була стратегією за замовчуванням для розв’язання двох голов з Git версії 0.99.9k до версії 2.33.0. -
resolve -
Це може вирішити лише дві гілки (тобто поточну гілку та іншу гілку, з якої ви витягли дані) за допомогою 3-стороннього алгоритму злиття. Він намагається ретельно виявити перехресні неоднозначності злиття. Він не обробляє перейменування.
-
octopus -
Це вирішує випадки з більш ніж двома заголовками, але відмовляється від складного об’єднання, яке потребує ручного вирішення. В основному це призначено для об’єднання заголовків тематичних гілок. Це стратегія об’єднання за замовчуванням під час витягування або об’єднання кількох гілок.
-
ours -
Це дозволяє вирішувати будь-яку кількість заголовків, але результуюче дерево злиття завжди буде таким, як поточна заголовка гілки, фактично ігноруючи всі зміни з усіх інших гілок. Це призначено для використання для заміни старої історії розробки бічних гілок. Зверніть увагу, що це відрізняється від опції
-Xoursдля стратегії злиттяort. -
subtree -
Це модифікована стратегія
ort. Під час об’єднання дерев A та B, якщо B відповідає піддереву A, B спочатку коригується відповідно до структури дерева A, замість того, щоб зчитувати дерева на одному рівні. Це коригування також виконується для дерева спільного предка.
Зі стратегіями, що використовують 3-стороннє злиття (включаючи ort за замовчуванням), якщо зміна внесена в обидві гілки, але пізніше скасована в одній з гілок, ця зміна буде присутня в результаті об’єднання; деякі люди вважають таку поведінку заплутаною. Це відбувається тому, що під час виконання злиття враховуються лише заголовки та база злиття, а не окремі коміти. Тому алгоритм злиття вважає скасовану зміну як таку, що взагалі не вносила змін, і замінює її зміненою версією.
КОНФІГУРАЦІЯ
Все, що знаходиться вище цього рядка в цьому розділі, не включено до документації git-config[1]. Наступний вміст такий самий, як і той, що знаходиться там:
|
Warning
|
Missing See original version for this content. |
GIT
Частина набору git[1]