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

НАЗВА

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

СИНОПСИС

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

ОПИС

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

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

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 відповідно.

ОБГОВОРЕННЯ

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

              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

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

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

	$ 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

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

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

	$ 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

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

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

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

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

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

Інформація із записів 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, щоб оновити topic до того, як вона буде готова до надсилання в upstream. Це призведе до повернення до тристороннього злиття, і це призведе до конфлікту так само, як і тестове злиття, яке ви розвʼязали раніше. Команда git rerere' буде виконана командою `git rebase, щоб допомогти вам розвʼязати цей конфлікт.

[NOTE] git rerere спирається на маркери конфлікту у файлі для виявлення конфлікту. Якщо файл вже містить рядки, які виглядають так само, як рядки з маркерами конфлікту, git rerere може не записати розвʼязання конфлікту. Щоб обійти це, можна використовувати налаштування conflict-marker-size у gitattributes[5].

GIT

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