Comments 24
Заранее извиняюсь за вольный перевод, но я старался передать смысл, а не быть гугл переводчиком )
Да вы правы, vimdiff, из коробки показывает BASE. Но не видно диффа, как при merge.tool = gitmerge. Вся прелесть заключается в том что сразу видны диффы между (A)-(B) и (A)-©.
Ну он поможет это просто заметить. Если тот кто делает merge не обладает достаточной компетенцией, чтоб решить что пойдет в D, он может просто спросить у тех кто эти изменения делал.
В данной статье я надеюсь продемонстрировать что процесс разрешения конфликтов может быть пошагово точным, при котором отпадает необходимость что-либо там угадывать.
После такого вступления я имею все основания ожидать математически точный ответ на поставленный выше вопрос. Надеюсь, понятно, что предложение «спросить у тех, кто делал», таковым не является и никак не относится к определению «пошагово точный», а «необходимость угадывать» так же никуда не девается. В общем случае, если правки были конкурентными, то с большой вероятностью будет конфликт интересов вносивших эти правки. Т.к. условный Вася не просто так выкинул строку целиком, а условный Петя не просто так внес в нее изменения. Каждый из них по видимому строил дальнейший код с учетом внесенной им же правки. Поэтому Петя посоветует выбросить правки Васи, а Вася — правки Пети. Вот такой вот «пошагово точный» процесс получается.
Но проблема в том, что это не ваша поэма, вы никогда не читали
эту поэму раньше, не были ответственны за написание или редактирование, и вы
отлично понимаете что в случае не верного решения чья-то тяжёлая работа может
кануть в небытие. Однако вас всё же назначили ответственным по слиянию этих
веток. Что же вам делать?
Срочно увольняться! Мерж должен делать тот кто модифицировал код. Если же политики доступа запрещают девелоперам делать мерж, есть ребейз и черри пик.
Мерж должен делать тот кто модифицировал код.
Попробуйте посоветовать это Торвальдсу. :)
На самом деле, в простом случае я согласен — очень удобно переложить все проблемы мержа на разработчиков конкретного изменения, заставляя их обеспечивать бесконфликтно прилагаемую ветку. Но это будет работать ой не всегда и не везде. И да, у конкретного автора может не быть права коммитить в общую ветку — поэтому я и говорю про то, что он должен обеспечить бесконфликтный мерж.
Если же политики доступа запрещают девелоперам делать мерж, есть ребейз и черри пик.
Дело ведь не в этом. Ребейз часто удобнее мержа, да, но часто и хуже. Особенно если что-то уже давно разработано и принято.
Оффтопик: "черри пик" звучит как карта. Черри треф, черри чирв :)
Попробуйте посоветовать это Торвальдсу. :)
И много людей работают в проектах уровня linux kernel?
Буквально из недавнего, накат коммита без конфликтов привел к падению сервиса, при том что на тестовом окружении все было нормально. Поэтому если есть возможность чтоб мерж делал разработчик, написавший код, именно он должен его делать.
Либо неправильно разбиты таски, неправильно составлен спринт, или же кто то полез в ту часть проекта за которую не отвечает.
diffuse на порядок отзывчевее, чем meld, но чуток беднее по функционалу.
Да вы правильно предположили, разрешение описанного конфликта делается ручной правкой текста.
Моя стратегия ручного слияния это взять весь текст из ветки с более весомыми изменениями
(в данном случае master/REMOTE т.е. beta), и поверх него производить пошаговые правки,
т.е. вносить изменения сделанные в другой ветке (master).
Да графический инструмент (meld) только подсветил изменения сделанные в каждой ветке, и сразу стало видно что в ветке beta цвета поменяли на hex коды, а в ветке master добавили капитализацию, пунктуацию и появился предлог "of" которого изначально без подсветки вообще было не заметить.
Но мне не очень нравится жанглировать окнами графического инструмента, поэтому я и предложил свой скрипт gitmerge, где всё сразу на одном экране, и если что в tmux'e каждый сплит можно зумить на весь экран.
Есть апстрим в котором активно пилят некий проект. Наша команда сделала форк и затачивает его под свои определенные задачи. Кто-то работает над одним классом кто-то над другим. Получается каждый разбирается и работает только с одной или двумя частями большого проекта.
Но в один ужасный момент надо смержить фиксы и новые фичи из апстрима. Было бы хорошо чтобы каждый мержил соответсвенно свою часть, потому что нету человека который знает все нюансы и может разрешить конфликты во всех частях проекта.
Подскажите что делать в этом случае?
Чуть более сложный вариант это создать отдельную мерж-ветку — то есть в форке некая ветка, которая начинается от того места, где мастер апстрима. И на ней последовательно делается следующее:
— Попытаться смержить в свой мастер
— Если без конфликтов, то победа
— Если есть конфликты, мерж отменяется, выбирается какой-то один конфликтный кусок и человек, который в этом разбирается, вносит такие правки, чтобы последующий мерж этого куска прошел уже без конфликтов. Делается коммит.
— Повторить
1) разработчик делает в своей ветке rebase master, разрешает конфликты.
2) ветка вливается в master.
3) переходят к следующему разработчику или ветке.
Должен же быть плагин для Atom, но пока не нашёл.
Безболезненное разрешение Merge конфликтов в Git