Стратегия ответвления мерзавца малочисленной [закрытой] команды разработчиков
3 ответа
Вам может пригодиться рабочий процесс, описанный Скоттом Чаконом в Pro Git . В этом рабочем процессе у вас есть две ветви, которые всегда существуют: master и develop .
master представляет собой наиболее стабильную версию вашего проекта, и вы можете развертывать ее в производственной среде только из этой ветки.
develop содержит изменения, которые находятся в процессе и не обязательно могут быть готовы к производству.
В ветке develop вы создаете тематические ветки для работы над отдельными функциями и исправлениями. Когда ваша функция / исправление будет готово к работе, вы объединяете его в develop , после чего вы можете проверить, как оно взаимодействует с другими тематическими ветками, в которые объединились ваши коллеги. После того, как develop находится в стабильном состоянии, объедините его с мастером . Развертывание в производственную среду с мастера всегда должно быть безопасным.
Скотт описывает эти давно работающие ветки как «разрозненные» фрагменты кода, где код из менее стабильной ветки в конечном итоге «переходит» в более стабильную после тестирования и общего утверждения вашей командой.
Пошагово ваш рабочий процесс в рамках этой модели может выглядеть следующим образом:
- Вам необходимо исправить ошибку.
- Создайте ветку под названием myfix , основанную на ветке develop .
- Работайте над ошибкой в этой ветке темы, пока она не будет исправлена.
- Объединить myfix в develop . Проведите тесты.
- Вы обнаруживаете, что ваше исправление конфликтует с другой веткой темы hisfix , которую ваш коллега объединил в develop , пока вы работали над исправлением.
- Внесите дополнительные изменения в ветку myfix , чтобы разрешить эти конфликты.
- Объедините myfix в develop и снова запустите тесты.
- Все работает нормально. Слить развернуть в мастер .
- Выполнять развертывание в производственной среде с мастера в любое время, потому что вы знаете, что он стабилен.
Дополнительные сведения об этом рабочем процессе см. В главе Ветвящиеся рабочие процессы в Pro Git.
В VCS наличие только «главной» ветви быстро показывает ее ограничения, потому что вы не можете проводить все усилия по разработке одновременно в одной ветке.
Это означает, что вам нужно знать , когда переходить .
Но в DVCS (как в «Децентрализованной» VCS) у вас также есть проблема публикации , с ветвями, которые вы сохраняете локальными по отношению к своим репозиториям, и ветвями, которые вы отправляете или извлекаете из них.
В этом контексте начните с определения ваших одновременных усилий по разработке и выберите процесс публикации (push / pull). Например (и это не единственный способ):
- prod - это общедоступная ветка только для чтения с кодом в производстве. Каждый может извлечь из него, чтобы:
- перебазировать его текущую разработку поверх него (для локального тестирования или для интеграции в локальный репозиторий разработчиков исправление, сделанное в репозитории prod в ветке prod)
- ветвь для добавления новых функций (из известного стабильного кода) ветвь
- для запуска следующей ветки выпуска (той, которая должна быть в производстве)
никто следует направлять непосредственно в prod (следовательно, только для чтения).
- релиз - это ветвь консолидации чтения-записи, где соответствующие коммиты выбираются для включения в следующий выпуск.
Каждый может нажать на выпуск, чтобы обновить следующий выпуск.
Каждый может извлечь из указанного выпуска, чтобы обновить свой локальный процесс консолидации. - featureX - это частная ветвь для чтения и записи (в том смысле, что ее не нужно отправлять в центральный репозиторий продукта), и его можно передавать / извлекать между репозиториями разработки. Он представляет среднесрочные и долгосрочные усилия, в отличие от ежедневного разработчика
- . Мастер представляет текущего разработчика и перемещается / вытягивается между репозиториями разработки.
Существуют и другие процессы управления выпуском, о чем свидетельствует этот вопрос SO .
Прочтите рабочий процесс ReinH Git для Agile-команд здесь: http://reinh.com/blog/2009/03/02/a-git-workflow-for- agile-team.html
Это очень хорошо работает для небольших команд. Цель здесь - убедиться, что все, что может быть потенциально нестабильным, попадет в какую-либо ветку. Выполняйте слияние с мастером только тогда, когда вы готовы к использованию всеми, кто работает за пределами функциональной ветки.
Примечание: эта стратегия вряд ли специфична для git, но git упрощает ее реализацию.