Git стратегия ветвления для небольшой команды разработчиков

У нас есть веб-приложение, которое мы обновляем и публикуем почти ежедневно. Мы используем git как наш VCS, и наша текущая стратегия ветвления очень проста и ломается: у нас есть ведущая ветвь, и мы проверяем изменения, которые нам "хороши" в ней. Это работает, но только до тех пор, пока мы не проверим нарушение.

Есть ли у кого-нибудь любимая стратегия отрасли git для небольших команд, которая отвечает следующим требованиям:

  • Хорошо работает для команд от 2 до 3 разработчиков
  • Легкий и не слишком большой процесс
  • Позволяет разработчикам с легкостью изолировать работу над исправлениями ошибок и более крупными функциями.
  • Позволяет нам поддерживать стабильную ветку (для тех, кто хочет, чтобы наши рабочие серверы работали),

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

ОТВЕТЫ

Ответ 1

Вы можете извлечь выгоду из рабочего процесса Скотт Чакон описывает в Pro Git. В этом рабочем процессе у вас есть две ветки, которые всегда существуют, ведутся и развиваются.

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

develop содержит изменения, которые выполняются и могут не обязательно быть готовыми к производству.

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

Скотт описывает эти длительные ветки как "силосы" кода, где код в менее устойчивой ветке, в конечном счете, "закончит", чтобы один из них стал более стабильным после тестирования и общего одобрения вашей командой.

Шаг за шагом, ваш рабочий процесс под этой моделью может выглядеть так:

  • Вам нужно исправить ошибку.
  • Создайте ветвь с именем myfix, основанную на ветке разработки.
  • Работа над ошибкой в ​​этой ветке темы до тех пор, пока она не будет исправлена.
  • Объединить myfix в разработке. Выполнить тесты.
  • Вы обнаружите, что ваши конфликты исправлений с другим тегом ветвления темы, с которым ваш коллега слился в разработку, пока вы работали над своим исправлением.
  • Сделайте больше изменений в ветке myfix, чтобы справиться с этими конфликтами.
  • Объединить myfix, чтобы снова и снова запускать тесты.
  • Все работает отлично. Слияние развивается в мастера.
  • Развертывание для создания из мастера в любое время, потому что вы знаете его стабильным.

Подробнее об этом рабочем процессе читайте в главе Ветвящиеся рабочие процессы в Pro Git.

Ответ 2

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

За последние 6 месяцев мне пришлось исправлять конфликты дважды. Я добавил шаги, чтобы всегда тестировать после слияния и "извлекать и объединять" или "тянуть - восстанавливать" много (один раз утром и днем) при разработке функций. Мы также использовали github.com как центральное место, чтобы вытащить последний код.

Ответ 3

(Сделал мой comment над своим собственным ответом, как и первоначально.)

От Скотта Чакона Гитуба:

Как мы это делаем Итак, что такое поток GitHub?

  • Все, что находится в главной ветке, развертывается
  • Чтобы работать над чем-то новым, создайте описательно названную ветку мастера (т.е. new-oauth2-scopes)
  • Фиксируйте эту ветвь локально и регулярно подталкивайте свою работу к той же именованной ветке на сервере.
  • Когда вам нужна обратная связь или помощь, или вы считаете, что филиал готов к слиянию, откройте запрос тяги
  • После того, как кто-то еще просмотрел и подписал, вы можете объединить его в мастер
  • Как только он будет объединен и нажат на "master", вы можете и должны немедленно развернуть

См. всю статью для более подробной информации: http://scottchacon.com/2011/08/31/github-flow.html

Обратите внимание, что "запросы на тягу" - это изобретение Гитуба, и это то, что запекло на их веб-сайте, а не Git себя: https://help.github.com/articles/using-pull-requests/

Ответ 4

Используйте ветвь master в качестве ветки разработки и создайте ветки выпуска для выполнения исправлений ошибок.

Любые новые функции будут отображаться master во время разработки (либо напрямую, либо как ветки темы с pull-запросами, до вас - не показаны на графике). После того, как все ваши запланированные функции реализованы, введите функцию замораживания и выполните тестирование. Когда вы счастливы, пометьте релиз на master как v1.0.

Со временем ваши пользователи обнаружат ошибки в v1.0, поэтому вы захотите создать ветку из этого тега (например, назовите ее после выпуска 1.0) и исправить эти ошибки в ветке. Когда у вас исправлено достаточное количество ошибок, вы считаете, что он гарантирует новый выпуск, пометьте его как v1.0.1 и объедините его обратно в master.

Между тем в ветке master может появиться новое окно разработки, которое в конечном итоге будет помечено как v1.1.

Промойте и повторите.

Это следует за семантическая версия для нумерации.

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

Ответ 5

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

Но в DVCS (как в "Децентрализованной" VCS) у вас также есть проблема публикации, с веткими, которые вы сохраняете локально ваши репозитории и ветки, на которые вы нажимаете или тянете.

В этом контексте начните с определения ваших параллельных усилий по разработке и выберите процесс публикации (push/pull). Например (и это не единственный способ):

  • prod - это публичное подразделение, доступное только для чтения, с кодом в процессе производства. Каждый мог бы извлечь из него, чтобы:
    • обновить его текущую разработку поверх него (для локального тестирования или для интеграции на локальном dev repo исправления, выполненного в prod repo на ветке prod)
    • для создания новых функций (от известного стабильного кода)
    • чтобы начать следующую ветку освобождения (тот, который должен быть в производстве)
      никто не должен нажимать непосредственно на prod (следовательно, только для чтения)
  • релиз - это ветвь консолидации чтения и записи, в которой соответствующие коммиты выбраны вишневыми, чтобы быть частью следующей версии.
    Каждый может нажать, чтобы освободить, чтобы обновить следующую версию.
    Каждый может выйти из упомянутого релиза, чтобы обновить свой локальный процесс консолидации.
  • featureX - это частная ветвь чтения-записи (в том, что ей не нужно нажимать на центральную репозицию prod), и ее можно вытолкнуть/вытащить между dev repos. Он представляет собой средние и долгосрочные усилия, отличные от ежедневных dev
  • master представляет текущий dev, и его выталкивают/вытягивают между репозиториями dev.

Существуют другие процессы управления версиями, так как этот вопрос SO подтверждает.

Ответ 6

Прочитайте ReinH Git Рабочий процесс для гибких команд здесь: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

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

Примечание. Эта стратегия вряд ли соответствует Git, но Git упрощает реализацию этой стратегии.