KDiff, решение конфликта объединения, как не дробить конфликтный блок на части? Опции

[G_Max]

В параллельных ветках в модуль добавляются разные функции.
При анализе объединения двух веток прога находит в функциях одинаковые строки и дробит конфликтный блок на части. Соответственно при объединении получается не схема
"Блок В + Блок С", а "Блок В(часть 1)+Блок С(часть 1)+общая строка+Блок В(часть 2)+Блок С(часть 2)".

Пример:
Ветка В

Функция СложитьЗначенияМассива(МассивЧисел)
Результат = 0;
Для Каждого ЭлементМассива Из МассивЧисел Цикл
Результат = Результат + ЭлементМассива;
КонецЦикла
Возврат Результат;
КонецФункции

Ветка С

Функция СложитьЗначенияТаблицы(ТаблицаЧисел)
Результат = 0;
Для Каждого ЭлементаТаблицы Из ТаблицаЧисел Цикл
Результат = Результат + ЭлементТаблицы;
КонецЦикла
Возврат Результат;
КонецФункции

Что хочется получить на выходе?

Функция СложитьЗначенияМассива(МассивЧисел)
Результат = 0;
Для Каждого ЭлементМассива Из МассивЧисел Цикл
Результат = Результат + ЭлементМассива;
КонецЦикла
Возврат Результат;
КонецФункции

Функция СложитьЗначенияТаблицы(ТаблицаЧисел)
Результат = 0;
Для Каждого ЭлементаТаблицы Из ТаблицаЧисел Цикл
Результат = Результат + ЭлементТаблицы;
КонецЦикла
Возврат Результат;
КонецФункции

Что позволяет сделать KDiff при решении конфликта?

Функция СложитьЗначенияМассива(МассивЧисел) // из В
Функция СложитьЗначенияТаблицы(ТаблицаЧисел) // из C

Результат = 0; // общая строка, не вызвала конфликт

Для Каждого ЭлементМассива Из МассивЧисел Цикл // из В
Результат = Результат + ЭлементМассива; // из В

Для Каждого ЭлементаТаблицы Из ТаблицаЧисел Цикл // из C
Результат = Результат + ЭлементТаблицы; // из C

КонецЦикла // общая строка, не вызвала конфликт
Возврат Результат; // общая строка, не вызвала конфликт
КонецФункции // общая строка, не вызвала конфликт

Можно ли заставить рассматривать как один блок конфликта указанный набор строк, а не брать автооценку KDiff'а, при которой он все дробит на запчасти?

Сообщение отредактировал G_Max - 12.2.2018, 11:15

[abm]

Да, спасибо, буду все, что в этой теме предложили курить и пробовать.
В организации будет скорее всего использоваться GitFlow(если этот вариант жестко завязан на использование плагина GitFlow). Если полноценная схема работы с удаленным репозиторием избавит от таких конфликтов, будет только хорошо.

Я не знаю что такое плагин GitFlow. Организация работы с GIT (т.е. используемый workflow) по идее должна поддерживаться всеми возможными клиентами, потому что с их стороны ничего, собственно, не меняется. Это только разные способы организации у управления ветками, хотя там и есть некоторые специфические штучки.
Я бы советовал не использовать всякие разные плагины и экстеншнс. Возьми полноценный нормальный клиент, тот же SourceTree.
На мой взгляд у него слишком усложненный интерфейс, но для "тонкой настройки" там есть все нужные прибамбасы.
Лично я использую встроенный в Visual Studio GIT, он несколько ограничен по функционалу, но покрывает 90% моих потребностей. Остальные 10% разруливаю в SourceTree.
Еще у меня живет Tortoise GIT - это расширение для виндовс экспортера, добавляет свои пункты в контекстное меню файловой системы. У него есть некоторые очень удобные фишки, ради которых я его и держу.

Насчет Gitflow workflow - я бы порекомендовал выбрать этот режим только если у вас цикл релизов жестко установлен заранее. Типа раз в две недели выкатываем новый релиз, вне зависимости от того, что мы там успели понаделать. Что успели, то и выкатываем.
Другой вариант - Feature Branches workflow больше заточен на "плавающий цикл" релизов. Типа релиз будет тогда, когда мы закончим фичи 1, 2 и 3, неважно когда мы их закончим, - завтра, через неделю или полгода.

Технически они примерно одинаковы, разница, по большому счету, в способе организации branches и принуждения разработчиков следовать некоторым правилам работы с branches.

[Romantic]

Специально зафиксировал как мы обычно работаем с гитом:

1. Делаем бранч на каждую фичу/фикс из dev-ветки
2. Работаем со своей веткой
3. Периодически pull-им изменения в локальную репу в ветке если над ней работают более чем один человек
4. Перед pull request'ом (или чаще, если надо) подмердживаем dev в свою ветку и разбираем конфликты если есть
5. merge в dev

[abm]

Специально зафиксировал как мы обычно работаем с гитом:

1. Делаем бранч на каждую фичу/фикс из dev-ветки
2. Работаем со своей веткой
3. Периодически pull-им изменения в локальную репу в ветке если над ней работают более чем один человек
4. Перед pull request'ом (или чаще, если надо) подмердживаем dev в свою ветку и разбираем конфликты если есть
5. merge в dev

Этот вариант не позволяет исключать из релиза ненужные пока или незаконченные фичи.
Плюс - сильно упрощает рефакторинг.

Сообщение отредактировал abm - 14.2.2018, 17:25

[Romantic]

Этот вариант не позволяет исключать из релиза ненужные пока или незаконченные фичи.
Плюс - сильно упрощает рефакторинг.

Ну почему?
В нужный момент релизная ветка бранчится от dev'а и стабилизируется отдельно.

[abm]

Ну почему?
В нужный момент релизная ветка бранчится от dev'а и стабилизируется отдельно.

Почему? Потому что:
1. Есть начальное состояние dev.
2. Из него делается branch "feature1". В какой-то момент делается merge feature1->dev.
3. Начинаем feature2 - делаем новый branch из dev.
4. Завершаем работу с feature2 и делаем merge feature2->dev
5. Прибегает начальник и говорит "делаем релиз, feature1 в релиз не идет, только feature2.
Вопрос - как?

И сопутствующий вопрос вдогонку - а как в этой модели вы хотфиксы делаете?

Сообщение отредактировал abm - 14.2.2018, 18:44

[G_Max]

Я не знаю что такое плагин GitFlow. Организация работы с GIT (т.е. используемый workflow) по идее должна поддерживаться всеми возможными клиентами, потому что с их стороны ничего, собственно, не меняется. Это только разные способы организации у управления ветками, хотя там и есть некоторые специфические штучки.
Я бы советовал не использовать всякие разные плагины и экстеншнс. Возьми полноценный нормальный клиент, тот же SourceTree.
На мой взгляд у него слишком усложненный интерфейс, но для "тонкой настройки" там есть все нужные прибамбасы.
Лично я использую встроенный в Visual Studio GIT, он несколько ограничен по функционалу, но покрывает 90% моих потребностей. Остальные 10% разруливаю в SourceTree.
Еще у меня живет Tortoise GIT - это расширение для виндовс экспортера, добавляет свои пункты в контекстное меню файловой системы. У него есть некоторые очень удобные фишки, ради которых я его и держу.
Насчет Gitflow workflow - я бы порекомендовал выбрать этот режим только если у вас цикл релизов жестко установлен заранее. Типа раз в две недели выкатываем новый релиз, вне зависимости от того, что мы там успели понаделать. Что успели, то и выкатываем.
Другой вариант - Feature Branches workflow больше заточен на "плавающий цикл" релизов. Типа релиз будет тогда, когда мы закончим фичи 1, 2 и 3, неважно когда мы их закончим, - завтра, через неделю или полгода.
Технически они примерно одинаковы, разница, по большому счету, в способе организации branches и принуждения разработчиков следовать некоторым правилам работы с branches.

У нас предполагается именно четкий выпуск релизов по расписанию. Так что Gitflow обязателен.
Сейчас пока временно притормозили запуск использования GIT из-за малого опыта работы с ним у большинства программистов, но его не избежать. Так что упомянутые клиентов посмотрю обязательно. Надеюсь нам устроят семинар, где и позадаем практические вопросы.

[abm]

У нас предполагается именно четкий выпуск релизов по расписанию. Так что Gitflow обязателен.

Я бы не сказал что прямо обязателен. Но с ним проще.
То же самое можно делать и с Feature branches workflow. Это все зависит не только от того, какой именно workflow используется, а еще и от того, насколько удается весь зоопарк разработчиков и тестеров (если есть) построить в правильном направлении.

[G_Max]

Я бы не сказал что прямо обязателен. Но с ним проще.
То же самое можно делать и с Feature branches workflow. Это все зависит не только от того, какой именно workflow используется, а еще и от того, насколько удается весь зоопарк разработчиков и тестеров (если есть) построить в правильном направлении.

Не, это требование с вершины пирамиды разработчиков. Не мне решать. Вот клиентов, которые эту схему позволят - на мой выбор.

[abm]

Не, это требование с вершины пирамиды разработчиков. Не мне решать. Вот клиентов, которые эту схему позволят - на мой выбор.

А если не секрет, вы что именно разрабатываете? Вернее, даже не так - какой IDE используется, если используется?

[G_Max]

А если не секрет, вы что именно разрабатываете? Вернее, даже не так - какой IDE используется, если используется?

В данном случае 1С.

[abm]

В данном случае 1С.

Я спросил про IDE потому что многие современные имеют на борту встроенную поддержку GIT. Какой IDE используется для 1С я не знаю.

[G_Max]

Я спросил про IDE потому что многие современные имеют на борту встроенную поддержку GIT. Какой IDE используется для 1С я не знаю.

Там своя среда, своя система управления версиями. С GIT не интегрируется. Но через выгрузку всей конфигурации в текстовые(XML) файлы можно использовать стороннюю систему. Что у нас и пытаются сделать.

[Romantic]

Почему? Потому что:
1. Есть начальное состояние dev.
2. Из него делается branch "feature1". В какой-то момент делается merge feature1->dev.
3. Начинаем feature2 - делаем новый branch из dev.
4. Завершаем работу с feature2 и делаем merge feature2->dev
5. Прибегает начальник и говорит "делаем релиз, feature1 в релиз не идет, только feature2.
Вопрос - как?

И сопутствующий вопрос вдогонку - а как в этой модели вы хотфиксы делаете?

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

Ну на крайняк можно сделать revert, но это такое...

Хотфиксы обычно в следующий релиз, но если прям срочно - бранч из релизной ветки и ее сборка.

[abm]

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

Это не совсем "жесткий цикл" релизов.
У вас, фактически, релизы основаны на готовности каких-то основных фич и определены жесткие даты этой готовности. С возможностью перенести релиз каких-то некритичных фич в следующий релиз. Т.е. это частный случай как раз варианта релизов по готовности фич, а не "каждые две недели и пофиг что там готово что нет". Может и ничего не готово, тогда релиз пропускается. Но в крупных продуктах\компаниях, с достаточно большим интервалов релизов такого обычно не бывает. Всегда что-то происходит между релизами.

Ну на крайняк можно сделать revert, но это такое...

Случаи крайянков я не рассматриваю. Мне интересны "академические" ситуации. Ясно что на крайняк можно хитроизвернуться тысячей возможных способов.

Хотфиксы обычно в следующий релиз, но если прям срочно - бранч из релизной ветки и ее сборка.

В твоем начальном описании процесса не было сущности "релизная ветка".
Есть dev, из нее делаются новые бренчи под каждую фичу, и в нее же назад сливаются.
Исходя из этой модели мне и не понятно стало, как вы _исключаете_ из релиза какие-то фичи, которые по каким-то причинам в релиз решено не включать. Твой ответ, насколько я это понял - "такого не бывает, у нас жесткий план, т.е. запланированная фича должна пойди в определенный релиз хоть убейся, и при этом есть заранее согласованный план релизов с постоянным и фиксированным интервалом".

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



А у нас как раз режим "релиз по готовности". Т.е. заранее известно что именно должно пойти в следующий релиз, мы обсуждаем ETA, делаем прогноз на дату релиза и пошла работа. Релиза не случается, пока нужные фишки не реализованы. Если по ходу там еще что-то накопиться, то вопрос "включать\не включать" в релиз принимает менеджер продукта. Обычно это возникает когда QA не успевает полностью оттестировать release candidate и все новые фишки и фиксы, которые в него включены.
Но у нас другая branching model, которая позволяет легко управлять "включать\не включать" и выпускать хотфиксы по мере необходимости. Нам именно это важно.
Правда, в нашей модели есть проблема с зависимостями между разными фишками, но она как-то решается. Несколько громоздко, но решается. Плюсом то, что разработчиков мало, - легче разруливать dependency conflicts.

[Romantic]

В твоем начальном описании процесса не было сущности "релизная ветка".
Есть dev, из нее делаются новые бренчи под каждую фичу, и в нее же назад сливаются.
Исходя из этой модели мне и не понятно стало, как вы _исключаете_ из релиза какие-то фичи, которые по каким-то причинам в релиз решено не включать. Твой ответ, насколько я это понял - "такого не бывает, у нас жесткий план, т.е. запланированная фича должна пойди в определенный релиз хоть убейся, и при этом есть заранее согласованный план релизов с постоянным и фиксированным интервалом".

Ну я потом написал что в какой-то момент бранчится релизная ветка и уже стабилизируется.
А все что в активной разработке идет в dev в который потом подмердживается стабилизированный релиз.

Правда, в нашей модели есть проблема с зависимостями между разными фишками, но она как-то решается. Несколько громоздко, но решается. Плюсом то, что разработчиков мало, - легче разруливать dependency conflicts.

У нас еще проще, наверное, проект компактный, команда разработки всего 5 человек.

[abm]

Ну я потом написал что в какой-то момент бранчится релизная ветка и уже стабилизируется.
А все что в активной разработке идет в dev в который потом подмердживается стабилизированный релиз.

Вот как раз это мне и непонятно.
В приведенной мной последовательности действий (как я понял у вас это происходит), нет никакой возможности исключить из релиза feature1 и включить только feature2, в какой бы момент вы не делали какие-то операции с релизной веткой или любыми другими ветками. Причина - feature2 _уже_ включает в себя feature1, потому что была сделана из dev с уже залитой туда feature1.

Совсем другой расклад был бы, если бы feature1 и feature2 делали из релизной ветки, а заливали назад в dev. В случае отсутствия зависимости в коде между feature1 и feature2 это позволило бы решить проблему исключения, и достаточно легко накатить хотфикс, если надо.

[Romantic]

Причина - feature2 _уже_ включает в себя feature1, потому что была сделана из dev с уже залитой туда feature1.

Ага, теперь понял что ты имеешь в виду. Ну да, есть такое.
Но так как у нас задачи мелкие то практически не возникает ситуации что в dev попадает фича, которую потом надо оттуда выковыривать по каким-то причинам.
Если же делается крупная фича, которая состоит из набора задач, то под нее выделяется отдельная ветка которая ветвится уже на задачи, она стабилизируется и уже потом мерджится в dev.

[abm]

Ага, теперь понял что ты имеешь в виду. Ну да, есть такое.
Но так как у нас задачи мелкие то практически не возникает ситуации что в dev попадает фича, которую потом надо оттуда выковыривать по каким-то причинам.
Если же делается крупная фича, которая состоит из набора задач, то под нее выделяется отдельная ветка которая ветвится уже на задачи, она стабилизируется и уже потом мерджится в dev.

У нас маленько по-другому. Я своих "построил" на несколько другой способ.
У нас есть master, который всегда, в любой момент времени точно соответствует опубликованному релизу.
Все новые фишки создаются из него и, по завершению, сливаются _только_ в dev. dev используется для общего тестирования и проверки что все в куче нормально работает с тестового сервера, а не только локально у девелоперов. По сути dev - большая куча, куда сливается все подряд.
Когда фишки, нужные для текущего релиза закончены, берется этот самый мастер, из него делается новый бренч ReleaseCandidate01VerNNNN и уже в него сливаются _только_ те фишки, которые надо включить в релиз. И он уходит на QA сервер, к тестерам. Если они дают зеленую отмашку, то этот бренч идет в продакшн.
Если нет, - финским (в своих бренчах) ошибки и делаем новый ReleaseCandidate02NNNN из первого с добавление фиксов, и так далее. Эти же фиксы накатываются и в dev.
Сразу в момент релиза обновляется master - он соответсвует последнему ReleaseCandidateNNNN и далее следующий цикл.
Если в это же самое время есть какие-то долгоиграющие фишки, которые начались давно и не закончены к моменту релиза, то обычно каждый девелопер в свои активные бренчи делает merge из последнего мастера.
Ну и с хотфиксами тоже понятно. Если надо, из мастера создается новая ветка HotFix01NNNN, в ней делаются изменения, которые накатываются тоже и в dev, и она идет в релиз, ну и master опять таки обновляется до состояния HotFix01NNNN.

[Romantic]

Разумно