Git с веткими разработки, постановки и производства

Эта статья звучит интересно, но я уверен, что диаграммы ошибочны. http://guides.beanstalkapp.com/version-control/branching-best-practices.html

Разве это не должно быть DEVELOPMENT > STAGING > PRODUCTION?

Слияния должны проходить только в одном направлении: от функции и исправлений ошибок сделанные в их собственной ветке или в разработке в стадию тестирования. После тестирования вы можете объединить эти изменения с производство.

Здесь я немного запутался. Итак, я объединил Staging to Master или Master to Staging?

Я использую клиент под названием SmartGit, и я запутался в этом вопросе. Обычно я делаю ветку для функции, фиксирую ее, затем переключаюсь на мастер и объединяю ее с веткой (вперед). Поэтому в этом новом рабочем процессе с Staging and Production я создаю эти две дополнительные ветки, а затем создаю ветку от master (aka dev) для моей функции. Закрепите его, затем переключитесь на Staging и слейте (вперед) в свою ветку функций? Правильно ли это звучит?

Собственно, что сделало это настолько запутанным, так это то, что люди Beanstalk стоят за своим нестандартным использованием Staging (это происходит до разработки на их диаграмме, и это не ошибка! https://twitter.com/Beanstalkapp/status/306129447885631488

Решили забыть о Beanstalk и просто с Гитубом.

Поскольку я опубликовал это, люди Beanstalk приняли мой намек и переименовали их этапы, теперь называя Development "Stable".

Ответ 1

Мысль здесь состоит в том, что вы проводите большую часть своего времени в development. В процессе разработки вы создаете ветвь feature (off development), завершаете эту функцию и затем снова объединяетесь в development. Затем его можно добавить к окончательной производственной версии, объединив ее в production.

Подробнее об этом подходе см. Успешная <В20 > Модель ветвления.

Ответ 2

Мы делаем другое, ИМХО проще: в master мы работаем над следующей крупной версией.

Каждая более крупная функция получает свою собственную ветвь (полученную от мастера) и будет регулярно перестраиваться разработчиком (+ сила) на вершине мастера (переполнение только отлично работает, если один разработчик работает над этой функцией). Если функция закончена, она будет только что переустановлена на master, а затем мастер переадресован на последнюю фиксацию функции. Чтобы избежать перезагрузки/принудительного нажатия, вы также можете регулярно сменять основные изменения в ветки функции и, если она закончит, объединить ветвь функции в мастер (обычное слияние или сквош-слияние). Но ИМХО делает ветвь функции менее ясной и затрудняет переупорядочение/очистку коммитов.

Если появится новый выпуск, мы создаем боковую ветвь из мастера, например. release-5, где исправляются только ошибки.

Ответ 3

Собственно, что сделало это настолько запутанным, так это то, что люди Beanstalk стоят за их нестандартным использованием Staging (это происходит до разработки на их диаграмме, и это не ошибка!

https://twitter.com/Beanstalkapp/status/306129447885631488

Ответ 4

одна из лучших вещей о git заключается в том, что вы можете изменить рабочий процесс, который лучше всего подходит вам. Я использую http://nvie.com/posts/a-successful-git-branching-model/ большую часть времени, но вы можете использовать любой рабочий процесс, который соответствует вашим потребностям.

Ответ 5

Из сообщение в моем блоге:

Рабочий процесс "gitflow" из nvie имеет две проблемы: он смущает изменяет значение "ведущей" ветки, и это не ясно оправдать стоимость дополнительной долгоживущей ветки. Обе проблемы может быть разрешено [...]