Является ли стратегия слияния, такая как Git Flow, действительно анти-паттерном?


30

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

В последнее время мы развлекались с этими ветками. Это была административная головная боль, гарантирующая, что вся работа превращается в каждую ветку, а некоторые ошибки, которые были исправлены в одной ветке, не превращаются в master, пока кто-то не укажет на это, что касается.

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

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

Я хотел бы знать - почему такая схема развития должна рассматриваться как анти-паттерн? Это действительно анти-шаблон?


1
Раздел «Правило 3» из старого поста Теда Дзюбы может помочь проиллюстрировать, как это может быть анти-паттерном.
Isxek

5
IMO, чем больше фактического времени вы тратите на размышления о контроле версий, тем больше ошибается весь пользовательский инструмент -> феномен в первую очередь.
Эрик Реппен

@ErikReppen: Я бы хотел отвлечь всех от контроля версий и предложить процесс, к которому каждый может привыкнуть. Таким образом, нам не нужно беспокоиться о таких вещах, как анти-паттерн или нет.
Макото

6
@Makoto Все, что нарушает KISS, является анти-паттерном, ИМО. Именно здесь опытные пользователи VCS сводят меня с ума.
Эрик Реппен

6
Термин «антипаттерн» является своего рода «лучшей практикой» в том смысле, что он часто служит оправданием для людей, чтобы отключить свой мозг. Не принимайте это понятие, если ведущий не может четко сказать вам, какой у него опыт и почему он плохой.
Kyralessa

Ответы:


30

Он в основном имеет в виду особенности ветвей модели. Ветви компонентов были объявлены анти-паттерном давным-давно, когда ветки длились месяцами, и системы контроля версий не могли объединиться, чтобы спасти их жизнь. В ветвях компонентов, которые длятся неделю или две, проблем гораздо меньше, особенно если вы постоянно объединяетесь с develop ветвью компонентов в течение этого времени. Что-нибудь намного дольше чем это все еще не рекомендуется.

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


3
Мой опыт работы с функциональными ветвями, или то, как мы их сделали, заключается в том, что с ними может быть душевная боль, если им разрешено жить больше, чем итерация. Правило, которое гласит, что все функции должны быть объединены в итерацию перед выпуском, было бы неплохо, чтобы облегчить душевную боль слияний - и, боже, если бы у нас была какая-то серьезная сердечная боль за этими ...
Makoto

6
Мой опыт заключается в том, что вы можете хранить локальные вещи, пока вы сохраняете их слитыми с недавним мастером и / или развиваться по мере необходимости.
Ян Худек

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

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

3
Вы правы. Они являются только антишаблоном, когда живут слишком долго без слияния. Иногда люди все еще выступают против идеи, когда они не помнят причины, лежащие в основе.
Карл Билефельдт

21

Слияние - забавная вещь: чем реже это делается, тем сложнее, чем сложнее, тем больше люди будут бояться этого, тем реже они будут это делать.

Решение - либо не допускать слишком больших отклонений ветвей, либо не использовать ветки.

Если люди это понимают, у вас, вероятно, не будет особых проблем со слиянием, если нет - возможно, филиалы не будут хорошей идеей без некоторого образования.


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

12
@makoto, довольно часто разъединение вещей в коде делает конфликты менее частыми. Это может быть либо простое разделение функциональности на функции / классы, либо более высокий уровень, позволяющий избежать недокументированных предположений между модулями. Тогда изменения становятся более локализованными.
maxim1000

1
@ maxim1000 Я согласен. Я думаю, что кто-то когда-то сказал что-то вроде: «VCS - это альтернатива модульной архитектуре для бедного человека»
8DH

+1 за первый абзац. И да, без образования gitflow-like это тупик
daitangio
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.