Ads
Comments 24
+2

Заранее извиняюсь за вольный перевод, но я старался передать смысл, а не быть гугл переводчиком )

+4
Забавно, но у меня трехсторонний merge получается просто сразу из коробки через vimdiff (той же самой командой git mergetool). Правда там четыре окна — LOCAL, BASE, REMOTE сверху и результат внизу.
0

Да вы правы, vimdiff, из коробки показывает BASE. Но не видно диффа, как при merge.tool = gitmerge. Вся прелесть заключается в том что сразу видны диффы между (A)-(B) и (A)-©.

0
Диффы видны и подсвечены, но, к сожалению, одной большой кучей — если в А и B строки одинаковы, а в C отличается, то вся строка будет подсвечена. Лечится тем, что подсветку можно выборочно включать/отключать командой :diffoff/:diffthis в нужном буфере — :diffoff в буфере А оставит подсвеченными только отличия между B и C. Тут уже вопрос привычки — для заядлых пользователей вима это норма, а для остальных людей не очень. Себя я отношу к первым.
+5
Я бы рекомендовал сразу взять готовую программу, которая поддерживает 3-way merge. Сам я пользовался kdif3, теперь использую Beyond Compare Pro. И тот и другой продукт умеют 3-way merge, разница в лицензиях и плюшках. Оба интегрируются как с мерком, так и с git'ом.
0
Отличная программа, тем более по NIX работает также.
А какой Ваш конфиг для нее, чтобы открывалось сразу в нужном виде?
0
Случай с розами слишком частный. Чем поможет 3-х колоночный анализ, если, например, в ветке B в строке N сделали изменения, а в ветке C строку N вообще удалили? Что оставить в D?
-1

Ну он поможет это просто заметить. Если тот кто делает merge не обладает достаточной компетенцией, чтоб решить что пойдет в D, он может просто спросить у тех кто эти изменения делал.

0
В данной статье я надеюсь продемонстрировать что процесс разрешения конфликтов может быть пошагово точным, при котором отпадает необходимость что-либо там угадывать.

После такого вступления я имею все основания ожидать математически точный ответ на поставленный выше вопрос. Надеюсь, понятно, что предложение «спросить у тех, кто делал», таковым не является и никак не относится к определению «пошагово точный», а «необходимость угадывать» так же никуда не девается. В общем случае, если правки были конкурентными, то с большой вероятностью будет конфликт интересов вносивших эти правки. Т.к. условный Вася не просто так выкинул строку целиком, а условный Петя не просто так внес в нее изменения. Каждый из них по видимому строил дальнейший код с учетом внесенной им же правки. Поэтому Петя посоветует выбросить правки Васи, а Вася — правки Пети. Вот такой вот «пошагово точный» процесс получается.
+1
Любой конфликт слияния требует внимательного изучения и ручного разрешения — я могу привести пример, когда все автоматически слилось, но не работает. Вопрос только в том, как сделать это изучение наиболее удобным, позволяя человеку сразу увидеть все нужные отличия.
-3
Но проблема в том, что это не ваша поэма, вы никогда не читали
эту поэму раньше, не были ответственны за написание или редактирование, и вы
отлично понимаете что в случае не верного решения чья-то тяжёлая работа может
кануть в небытие. Однако вас всё же назначили ответственным по слиянию этих
веток. Что же вам делать?


Срочно увольняться! Мерж должен делать тот кто модифицировал код. Если же политики доступа запрещают девелоперам делать мерж, есть ребейз и черри пик.
+1
Мерж должен делать тот кто модифицировал код.

Попробуйте посоветовать это Торвальдсу. :)
На самом деле, в простом случае я согласен — очень удобно переложить все проблемы мержа на разработчиков конкретного изменения, заставляя их обеспечивать бесконфликтно прилагаемую ветку. Но это будет работать ой не всегда и не везде. И да, у конкретного автора может не быть права коммитить в общую ветку — поэтому я и говорю про то, что он должен обеспечить бесконфликтный мерж.


Если же политики доступа запрещают девелоперам делать мерж, есть ребейз и черри пик.

Дело ведь не в этом. Ребейз часто удобнее мержа, да, но часто и хуже. Особенно если что-то уже давно разработано и принято.


Оффтопик: "черри пик" звучит как карта. Черри треф, черри чирв :)

0
Попробуйте посоветовать это Торвальдсу. :)

И много людей работают в проектах уровня linux kernel?

Буквально из недавнего, накат коммита без конфликтов привел к падению сервиса, при том что на тестовом окружении все было нормально. Поэтому если есть возможность чтоб мерж делал разработчик, написавший код, именно он должен его делать.
-6
Имхо если возник конфликт, значит что то не так с менеджментом проекта,
Либо неправильно разбиты таски, неправильно составлен спринт, или же кто то полез в ту часть проекта за которую не отвечает.
0
Использую diffuse с четырьмя колонками: remote, base, local, current(result).
diffuse на порядок отзывчевее, чем meld, но чуток беднее по функционалу.
UFO landed and left these words here
0

Да вы правильно предположили, разрешение описанного конфликта делается ручной правкой текста.


Моя стратегия ручного слияния это взять весь текст из ветки с более весомыми изменениями
(в данном случае master/REMOTE т.е. beta), и поверх него производить пошаговые правки,
т.е. вносить изменения сделанные в другой ветке (master).

Да графический инструмент (meld) только подсветил изменения сделанные в каждой ветке, и сразу стало видно что в ветке beta цвета поменяли на hex коды, а в ветке master добавили капитализацию, пунктуацию и появился предлог "of" которого изначально без подсветки вообще было не заметить.


Но мне не очень нравится жанглировать окнами графического инструмента, поэтому я и предложил свой скрипт gitmerge, где всё сразу на одном экране, и если что в tmux'e каждый сплит можно зумить на весь экран.

0
А кто знает как быть с таким случаем:
Есть апстрим в котором активно пилят некий проект. Наша команда сделала форк и затачивает его под свои определенные задачи. Кто-то работает над одним классом кто-то над другим. Получается каждый разбирается и работает только с одной или двумя частями большого проекта.
Но в один ужасный момент надо смержить фиксы и новые фичи из апстрима. Было бы хорошо чтобы каждый мержил соответсвенно свою часть, потому что нету человека который знает все нюансы и может разрешить конфликты во всех частях проекта.
Подскажите что делать в этом случае?
+1
Мержить чаще. В том числе и разбивать мерж на несколько — сначала подтянуть «от начала и до этого места», потом от «от этого места и до конца». Еще разумнее мержить по фичам — сначала вмержим к себе эту фичу, потом следующую, потом еще одну.

Чуть более сложный вариант это создать отдельную мерж-ветку — то есть в форке некая ветка, которая начинается от того места, где мастер апстрима. И на ней последовательно делается следующее:

— Попытаться смержить в свой мастер
— Если без конфликтов, то победа
— Если есть конфликты, мерж отменяется, выбирается какой-то один конфликтный кусок и человек, который в этом разбирается, вносит такие правки, чтобы последующий мерж этого куска прошел уже без конфликтов. Делается коммит.
— Повторить
0
По возможности фичи стартовать каждый раз от стабильной ветки, а не продолжать одну и ту же. Это или заставить мерджить чаще (нужен код из соседних фич) или по крайней мере вовремя обозначит проблему.
0
Немного внешней координации, и можно действовать по такой схеме:

1) разработчик делает в своей ветке rebase master, разрешает конфликты.
2) ветка вливается в master.
3) переходят к следующему разработчику или ветке.
0
Разбить работу над форком на отдельные ветки на которых работают компетентные в своей части разработчики и когда придет время забрать изменения со стороны, делать мердж с апстримом по очереди в каждой из них, последний мерджер и получит финальный вариант. Минус только в том, что если разработчики где-то все-таки пересекаются по коду, им придется заново разрешать конфликты которые они уже разрешали сливая свои ветки в мастер вашей версии ранее.
Only those users with full accounts are able to leave comments.  , please.