модульная разработка, git и постоянные конфликты при merge

Потому что в гите самая убогая мёржилка. Но фанбоям не понять.

git flow же.

И какой же алгоритм используется в git merge?

Не могли бы вы нам прояснить его сильные и слабые стороны, особенно в сравнении с другими алгоритмами слияния, желательнно применяемыми лично вами на практике?

приходится повторно разрешать то что 10 раз разрешалось до этого.

ты что-то делаешь не так

фиче ветки живут и не вливаются в мастер

т.к. клиенту надо фичу1, фичу3, а фичу2 не надо.

git co master git co -b release_client_1 git merge feature1 git merge feature2

git co master git co -b release_client_2 git merge feature1 git merge feature2 git merge feature5

git co master git co -b release_client_3 git merge feature1 git merge feature5

не могу я feature_N принять в мастер.

тематические ветки часто изменяют/дополняют одни и те же файлы.

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

т.к. клиенту надо фичу1, фичу3, а фичу2 не надо.

Все фичи взаимоисключающие?

Такое ощущение, что ты механически совершаешь действия, не особо понимая их смысла.

А в darcs таких проблем нет...

Я его не использовал. Но Darcs, похоже, настолько тормозной, что даже GHC перешёл на Git (Darcs пишется на Haskell).

согласен в части разделения. новый код пишется разделенным.

фичи некоторые дополняющие (т.е. в код одной включена другая)

прямо конфликтных взаимоисключающик фич нет.

Формально гит не может за тебя решить какую версию правки применить. Необходимо минимизировать одновременную правку кода. Далее почитай про стратегии мерджа.

Так что гит не причем тут - ни одна VCS не сможет решать за кого-то чей код «лучше»

Во-первых, вести ветку develop, куда постепенно мержить все фичи. По созданию релиза можно будет как develop мержить в master, так и отдельно feature-ветки (если есть на то причины), так как в них уже будут учтены изменения в других feature-ветках, сделанных другими разработчиками.

Иными словами, разработчики должны взаимодействовать непрерывно, а не по выходу релиза. Если я правильно понял проблему...

Очевидно у тебя не модули, а какое-говно, если они шарят одинаковые файлы. Vcs в данном случае бессильна.

Мержи все фичи в master и оборачивай их в ifdefы.

Создание релиза выглядит как мердж в мастер набора тематических веток

То есть клиенты получают одинаковый код? Тогда ifdef с настройкой через configure.

git merge
сильные стороны

Невозможна ситуация «всё хорошо, прекрасная маркиза». Конфликты видны, вместо них не будет молча создана лажа.

прямо конфликтных взаимоисключающик фич нет.

Тогда нужно всё смержить в мастер и избавиться от feature бранчей, они нужны только на время разработки фичи. Кастомизировать набор фич нужно через систему сборки.

Ну, т.е. описание процесса ты не почитал.

что то вы делаете не так.

У тебя с архитектурой косяки, а не с гитом.

Потому что в гите самая убогая мёржилка.

Мальчик, ты дурак?

На Хабре недавно статья была про ветки у разработчиков хрома. Так вот: веток там нет, а включение-отключение опций делаются прямо в коде

if(featureOneEnabled) {фигачим код}

Так, по-моему, гораздо лучше, чем искать, какие ветки ОК, какие не ОК, что смержилось, а что лажает. Если кто против - выкладываешь пример хрома: гугле, громадный проект, все работает, значит, и у нас покатит.

На Хабре недавно статья была про ветки у разработчиков хрома. Так вот: веток там нет

Может быть за одно они ещё сидят на ламповом svn?

а для каждого клиента набор модулей постоянно меняется?

из невнятных показаний ТС я понял что у них есть «корка» и в корку перед билдом мержать набор «плагинов» под каждого клиента.

и таки да. на каком языке проект?

А тебе в голову не приходило что для этого как раз и придумали условную компиляцию и модульный подход к программированию? Сами себе проблем насоздают, а потом плохие инструменты разного рода и языки программирования.

С момента перехода ghc на гит, даркс заметно ускорили, но имхо он более инопланетянский в использовании нежели гит.

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

Конкретно гугль сидит на своем децентрализованном велосипеде, коли пресса не врет.

А SVN вполне себе хороший хлопец, раз уж проект не однодневка и имеет какой-никакой центральный сервер. Проблем от излишней веткизации точно не будет, бранчить SVN - дурных нема.

Веб приложение на php (yii1) досталось мне с плохим наследием.

тогда рефакторинг, реализация точек расширения и плагинов.

Конкретно гугль сидит на своем децентрализованном велосипеде, коли пресса не врет.

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

А SVN вполне себе хороший хлопец

Был таковым когда из альтернатив было только CVS. Сейчас им по своей воле в разработке пользуются только овощи которые не осилили перестроить стиль разработки с файлопойки на что-то более вменяемое.

раз уж проект не однодневка и имеет какой-никакой центральный сервер

Это уже что-то из области психиатрии.

А что в perforce такого криминального?

...

Ну, в общем, да, не знаю никого, кто сегодня начинал бы кодить в SVN.

И все-таки: у прожекта есть Jira, Bamboo, почтовик,можно и SVN-сервер добавить, никто не похудеет. Лично мне тут нужны три вещи: коммит, роллбак к ревизии, дифф. Вишенка на торте ­— периодические релиз-версии. SVN вполне хватило бы; но в средних/больших командах не работал, не знаю, что там может действительно понадобиться, а что — понту ради.

смержи мастер по очереди в каждую ветку

по-ходу проблема в том что у него в разных ветках изменения одинх и тех-же файлов + для разных клиентов нужен разный набор из энного кол-ва одних и тех-же веток, ну типа для одного клиента нужны ветки 1,3,4 и 6, а для второго нужны только 3,4 и 7, и как-бы во всех этих ветках есть пересекающиеся изменения в index.php

Ну этого мы не знаем, но если это так, то я умываю руки. Но всё равно проще хорошо подумать и в разные ветки поделать мерж-коммиты с нужными изменениями.

смержи мастер по очереди в каждую ветку

С этого начинать нужно! Перед каждым важным изменением, после каждого важного изменения, а также утром и вечером.

У SVN в 2015-м году слишком узкая специализация. В качестве аналогии: керамический нож полезен в ресторане, но дома обычно деньги на ветер.

Путать код и настройки - ССЗБ. Я сам не безгрешен, чтобы бросать камень, но при изначальной куче клиентов всё-таки можно было догадаться про недостаточность конфигов.

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

То есть они категорически против отдельных веток на каждого клиента и каждый раз мёржат с нуля?

А SVN вполне себе хороший хлопец

Был таковым когда из альтернатив было только CVS. Сейчас им по >своей воле в разработке пользуются только овощи которые не >осилили перестроить стиль разработки с файлопойки на что-то >более вменяемое.

Или работодатель не видит необходимости переходить. Для меня это может повлиять к каких-то пограничных случаях, но не главный критерий.

но в средних/больших командах не работал, не знаю, что там >может действительно понадобиться

Несколько людей пилят фичи днями/неделями и им нужно часто обновляться из апстрима, но их попытка смёржить обратно всё сломает. Здесь SVN в глубокой [Роскомнадзор].

Создание релиза выглядит как мердж в мастер набора тематических веток при этом возникают конфликты т.к. тематические ветки часто изменяют/дополняют одни и те же файлы.

В гите тематические ветки имеют совсем другой смысл. Читать git help workflows до просветления.

... но в средних/больших командах не работал, не знаю, что там может действительно понадобиться

Работа в команде на самом деле не добавляет каких-либо существенно новых требований к VCS. Что вообще нужно одниночному разработчику для комфортной работы, кроме очевидных фич:

• нормальные ветки с мержами,
• возможность смотреть локально историю (log, annotate, blame, grep по коммитам ...),
• возможность локально делать коммиты,
• хотя бы локально иметь возможность редактировать коммиты (это все фичи git'ового rebase).

Под локальностью подразумевается работа без доступа к сети. Subversion ничего из этого не умеет. Формально, конечно, есть ветки через одно место, но в совокупности с мержем работа с ними превращается в настоящее адище. Svn годится только для помойки блобов.

Наличие команды в поректе влияет только на способ работы с репозиторием (что называется workflow на буржуйском) и быть может способность VCS работать с разными пользователями.

Или работодатель не видит необходимости переходить...

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

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

Для меня это может повлиять к каких-то пограничных случаях, но не главный критерий.

Это же не только вопрос предпочтений, инструментарий оказывает немалое влияние на эффективность работы. Знаешь ли, svn репозитории со временем имеют привычку сильно вырастать в размере так, что на какие-то svn {status,update...} начинают уходить десятки секунд или минуты. И это совсем не прикольно.

Ну-ка, по-подробнее про p4, а то я к нему только начал присматриваться.

в точку. только не index.php а овер дофига разных файлах