українська мова ▾ Topics ▾ Latest version ▾ git-rerere last updated in 2.39.0

НАЗВА

git-rerere - Повторно використати записане вирішення конфліктних злиттів

СИНОПСИС

git rerere [clear | forget <pathspec>…​ | diff | status | remaining | gc]

ОПИС

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

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

Note
 Щоб увімкнути цю команду, потрібно встановити змінну конфігурації rerere.enabled.

КОМАНДИ

Зазвичай, «git rerere» виконується без аргументів чи втручання користувача. Однак, він має кілька команд, які дозволяють йому взаємодіяти зі своїм робочим станом.

clear

Скиньте метадані, що використовуються rerere, якщо процес злиття має бути перервано. Виклик git am [--skip|--abort] або git rebase [--skip|--abort] автоматично викличе цю команду.

forget <pathspec>

Скинути налаштування розв’язання конфліктів, які rerere записав для поточного конфлікту в <pathspec>.

diff

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

status

Вивести шляхи з конфліктами, розв’язання злиття яких буде записано.

remaining

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

gc

Видаляє записи конфліктних злиттів, які відбулися давно. За замовчуванням видаляються невирішені конфлікти, старші за 15 днів, та вирішені конфлікти, старші за 60 днів. Ці значення за замовчуванням контролюються за допомогою змінних конфігурації gc.rerereUnresolved та gc.rerereResolved відповідно.

ОБГОВОРЕННЯ

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

              o---*---o topic
             /
    o---o---o---*---o---o master

Для такого тесту вам потрібно якимось чином об’єднати master та topic. Один зі способів зробити це – перетягнути master у гілку topic:

	$ git switch topic
	$ git merge master

              o---*---o---+ topic
             /           /
    o---o---o---*---o---o master

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

Після цього тестового злиття є два способи продовжити роботу над темою. Найпростіший – це будувати на основі тестового коміту злиття +, і коли ваша робота в тематичній гілці нарешті буде готова, перетягнути тематичну гілку в головну гілку та/або попросити апстрім витягнути її від вас. Однак на той час головна гілка або апстрім могли бути просунуті з моменту тестового злиття +, і в цьому випадку остаточний графік комітів виглядатиме так:

	$ git switch topic
	$ git merge master
	$ ... робота як над тематичною, так і над основною гілками
	$ git switch master
	$ git merge topic

              o---*---o---+---o---o topic
             /           /         \
    o---o---o---*---o---o---o---o---+ master

Однак, якщо ваша тематична гілка існує довго, вона матиме багато таких комітів "Злиття з головної гілки", що зайво захаращуватиме історію розробки. Читачі списку розсилки ядра Linux можуть пам’ятати, що Лінус скаржився на такі занадто часті тестові злиття, коли розробник підсистеми попросив витягнути дані з гілки, повної "марних злиття".

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

	$ git switch topic
	$ git merge master
	$ git reset --hard HEAD^ ;# rewind the test merge
	$ ... робота як над тематичною, так і над основною гілками
	$ git switch master
	$ git merge topic

              o---*---o-------o---o topic
             /                     \
    o---o---o---*---o---o---o---o---+ master

Це залишить лише один коміт злиття, коли ваша тематична гілка нарешті буде готова та об’єднана з головною гілкою. Це злиття вимагатиме від вас вирішення конфлікту, що виник через коміти, позначені *. Однак, цей конфлікт часто є тим самим конфліктом, який ви вирішили, створюючи тестове злиття, яке ви усунули. git rerere допоможе вам вирішити це остаточне конфліктне злиття, використовуючи інформацію з вашого попереднього ручного вирішення.

Виконання команди git rerere одразу після конфліктного автозлиття записує файли робочого дерева конфліктів зі звичайними маркерами конфліктів <<<<<<<, ======= та >>>>>>. Пізніше, після того, як ви завершите вирішення конфліктів, повторний запуск git rerere запише вирішений стан цих файлів. Припустимо, ви зробили це, коли створювали тестове злиття master у тематичну гілку.

Наступного разу, після того, як ви побачите те саме конфліктне автозлиття, запуск git rerere виконає тристороннє злиття між попереднім конфліктним автозлиттям, попереднім ручним вирішенням та поточним конфліктним автозлиттям. Якщо це тристороннє злиття вирішиться чисто, результат записується у ваш робочий файл дерева, тому вам не доведеться вирішувати його вручну. Зверніть увагу, що git rerere залишає індексний файл без змін, тому вам все одно потрібно виконати остаточну перевірку на працездатність за допомогою git diff (або git diff -c) та git add, коли ви будете задоволені результатом.

Для зручності, git merge автоматично викликає git rerere після виходу з невдалим автозлиттям, а git rerere записує результат роздачі, якщо це новий конфлікт, або повторно використовує попередній результат роздачі, якщо це не так. git commit також викликає git rerere під час коміту результату злиття. Це означає, що вам не потрібно робити нічого особливого самостійно (окрім увімкнення змінної конфігурації rerere.enabled).

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

Інформація із записів git rerere також використовується під час запуску git rebase. Після завершення тестового злиття та продовження розробки тематичної гілки:

              o---*---o-------o---o topic
             /
    o---o---o---*---o---o---o---o   master

	$ git rebase master topic

				  o---*---o-------o---o topic
				 /
    o---o---o---*---o---o---o---o   master

Ви можете виконати команду git rebase master topic, щоб оновити тему до того, як вона буде готова до відправки в головну версію. Це призведе до повернення до тристороннього злиття, і це призведе до конфлікту так само, як і тестове злиття, яке ви вирішили раніше. Команда git rerere' буде виконана командою `git rebase, щоб допомогти вам вирішити цей конфлікт.

[ПРИМІТКА] «git rerere» спирається на маркери конфлікту у файлі для виявлення конфлікту. Якщо файл вже містить рядки, які виглядають так само, як рядки з маркерами конфлікту, «git rerere» може не записати вирішення конфлікту. Щоб обійти це, можна використовувати налаштування conflict-marker-size у gitattributes[5].

GIT

Частина набору git[1]