Управление релизами с системой управления распределенной версией

Question

Мы рассматриваем переход от SVN к распределенному VCS на моем рабочем месте.

Я знаком со всеми причинами желания использовать DVCS для повседневной разработки: локальный контроль версий, более легкое разветвление и слияние и т. Д., Но я не видел столько, что убедительно в терминах управления версиями программного обеспечения. Вот наш выпуск:

• Узнайте, какие изменения доступны для слияния.
• Заполните запрос, чтобы найти дефекты/билеты, связанные с этими изменениями.
• Отфильтровать изменения, связанные с "открытыми" билетами. В нашей среде билеты должны находиться в закрытом состоянии, чтобы слиться с филиалом выпуска.
• Отфильтруйте изменения, которые мы не хотим в ветви релиза. Мы очень консервативны, когда речь идет о слиянии изменений. Если изменение не является абсолютно необходимым, оно не объединяется.
• Объединить имеющиеся изменения, желательно в хронологическом порядке. Мы группируем изменения вместе, если они связаны с одним и тем же билетом.
• Заблокируйте нежелательные изменения из ветви освобождения (svnmerge block), поэтому нам не придется иметь дело с ними снова.

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

Я уже возился с git, mercurial и пластиком, и насколько я могу судить, ни один из них не очень хорошо относится к этой модели. Похоже, что они будут работать очень хорошо, когда у вас будет только один продукт, который вы выпускаете, но я не могу себе представить, как использовать их для манипуляции несколькими, очень разными продуктами из одной и той же базы кода.

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

DVCS, по-видимому, лучше подходит для филиалов функций. Нет необходимости в наборе вишни, если вы сливаетесь непосредственно из ветки функций в магистраль и в отделении выпуска. Но кто хочет делать все, что сливается все время? И как вы запрашиваете, что доступно для слияния? И как вы убедитесь, что все изменения в ветви признака совпадают? Это звучит как полный хаос.

Я разорван, потому что кодер во мне хочет DVCS для повседневной работы. Я действительно хочу это. Но я боюсь того дня, когда я должен поставить шляпу менеджера релиза и разобраться, что нужно объединить, а что нет. Я хочу написать код, я не хочу быть обезьяной слияния.

Answer 1

Вы действительно хотите использовать git в этой ситуации, потому что он настолько превосходен, когда речь заходит о слиянии и управлении выпуском. Git разрешает процесс подписания изменений для выхода в релиз; он фактически обеспечивает поддержку нескольких уровней управления выпуском, именно потому, что именно так управляется Linux.

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

Git также позволяет вам вносить вилку в коллекцию изменений в один патч для отправки вверх по течению, поэтому вам не нужно переносить все исправления «oops, that not very work» в ветвь release или репозиторий, только приятная чистая функция или исправления исправлений.