Фича-бранч схема

Но тогда вместо работы будут одни сплошные мержи (команда-то большая)

И все одновременно пилят одну и ту же функцию/класс?

Хочется для релиза собирать набор фичей, которые реально готовы.

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

И все одновременно пилят одну и ту же функцию/класс?

Проблема в том, что проект постоянно рефакторят (он находится на такой стадии, так что не рефакторить - не предлагать). И да, коль есть много переиспользуемых компонентов, пересечся вероятность очень большая.

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

Предположим, что разработчик А собрал такой патч. Разработчик Б так же собрал патч, но без учета того, что на стейбл уже накатили патч от разработчика А. В итоге патч от Б не наложится и он (Б) должен будет мержить стейбл себе и пересобирать патч. В конечном итоге все разработчики должны будут перемержиться, что бы собрать такой патч.

Долго смотрел в вот это: http://martinfowler.com/bliki/FeatureBranch.html

Ощущение такое, что проблема не имеет решения.

В итоге патч от Б не наложится и он (Б) должен будет мержить стейбл себе и пересобирать патч

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

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

Ядро - это совсем другое. Там же драйвера в основном. Да и никто его так жестко не рефакторит.

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

есть девелопмент ветка и куча фича-бранчей...

Не понял отличия от моей схемы.

Ну если ты это и имел виду, то никакой =)

Я просто уточнил, что в 100% изоляции бранчи вести нельзя - хрен потом смержишся в конце фичи.

Я просто уточнил, что в 100% изоляции бранчи вести нельзя

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

> Лучше мержить помногу и часто, чем редко и большими портянками.

O_o

Может, «поНЕмногу и часто»?

В случае «один бранч - один девелопер» в роли бранча лучше использовать patch queue в терминах Mercurial (ХЗ как это называется в Git), а вместо merge делать rebase, если это возможно.

Может, «поНЕмногу и часто»?

Чорт, да, именно так.

Может, «поНЕмногу и часто»?

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

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

>Проблема в том, что проект постоянно рефакторят

Гм. Помечать удаляемый функционал как deprecated и давать остальным неделю на дорефакторить?

Например, при переименовании метода старый вариант ещё неделю гарантированно вызывает новый с теми же аргументами (и руганью).

Disclaimer: нет, я не считаю себя докой в рефакторинге, и тем более в распределённой разработке.

Типичный пример: переименование метода

Дык это, man darcs:

replace

Replace allows you to change a specified token wherever it occurs in the specified files. The replace is encoded in a special patch and will merge as expected with other patches. Tokens here are defined by a regexp specifying the characters which are allowed. By default a token corresponds to a C identifier.

Дык это, man darcs:

Дык, такие изменения можно и руками сделать. Зачастую рефакторинг это изменение сигнатуры метода и чем тут поможет darcs?

>Зачастую рефакторинг это изменение сигнатуры метода и чем тут поможет darcs

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