Рабочие процессы Git: перебазирование опубликованных/общих веток

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

Использование pull --rebase для меня теперь не проблема. Однако у нас также есть большие ветки функций, над которыми работают несколько человек. Периодически мы хотим вносить изменения, которые происходят на master. Здравый смысл подсказывает нам слияние, так как это общая ветвь. Однако в нашей одержимости перебазированием мы решили перебазировать эти ветки. Конечно, это требует всеобщего сотрудничества. Рабочий процесс выглядит примерно так:

1) Rebaser координирует свои действия со всеми, чтобы убедиться, что все они зарегистрированы и отправлены в функциональную ветку, а затем просит их больше не выполнять работу в этой ветке, пока они не получат все чистый.

2) Ребазер перебазирует ветку фичи на главную, удаляет удаленную ветку фичи (git push origin :feature), а затем помещает новую, перебазированную ветку фичи (git push origin feature)

3) Ребазер каждый извлекает, который обновляет свою ветвь функций, затем удаляет свою локальную ветвь функций (функция git branch -D), затем создает новую локальную ветвь функций, которая отслеживает удаленную ветвь функций. Затем все получают полную ясность.

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

С другой стороны, история нашего репозитория прекрасна.

Что вы думаете, гуру Git? Мы играем с огнем или качаем разумный рабочий процесс?

ОБНОВЛЕНИЕ:

Прошло два года с тех пор, как я впервые задал вопрос, и с тех пор мой рабочий процесс изменился. Мы по-прежнему регулярно выполняем git pull --rebase, так что ничего не изменилось. Это здравый смысл, и он предотвращает все неприглядные, запутанные мини-слияния. (В основном мы поддерживаем синхронизацию, поэтому git pull --rebase не требует больших затрат).

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

Наше решение состоит из нескольких компонентов:

• Ветка master является «нетронутой».Тематические ветки объединяются, и как только они это делают, тематическая ветка удаляется. Другими словами, слияние тематической ветки означает, что эта работа готова к производству и теперь является частью основной ветки. Глядя на нашу историю версий, становится очень ясно, что происходит: тематические ветки сливаются в главную, вот и все.

• При необходимости мы используем одноразовые ветки интеграции. Например, если у нас есть тематические ветки A, B и C, и ни одна из них не готова к интеграции в master, но нам нужно протестировать их вместе, мы просто создаем ветку QA (обычно вне master), а затем объединяем A, B и C in. В какой-то момент ветка QA удаляется или используется повторно. Дело в том, что она никоим образом не предназначена для постоянного использования и не имеет тех же ограничений, что и основная ветка (вы можете объединять свои тематические ветки столько раз, сколько хотите). Если история становится слишком запутанной, вы можете просто удалить ветку QA и начать заново (подход, который мы нашли очень естественным).

• При слиянии всегда используйте git merge --no-ff. Это такой огромный отход от нашей навязчивой идеи «линейной истории коммитов» двухлетней давности, что он заслуживает комментария. Теперь, когда мы смягчились в отношении линейной истории коммитов и увидели, что слияния хороши и полезны, мы начали полагаться на тематические ветки, которые являются настоящими ветвями вне мастера, а не просто серия коммитов, которые в конечном итоге становятся одним целым с мастером. git merge --no-ff гарантирует, что всегда будет фиксация слияния, даже если в этом нет необходимости.

• У нас есть хорошо понятное соглашение для сообщений коммитов и веток, и, что более важно, оно перекрестно ссылается на нашу систему отслеживания проблем.Наша система отслеживания проблем использует числовые номера проблем, и для любой функции (или дефекта) у нас есть номер проблемы (например, 1234). Если вы работаете над этой проблемой, вы должны создать ветку _1234 и начинать каждое сообщение коммита с "_1234: делать бла-бла". Это может показаться немного навязчивым, но это действительно хорошо сработало для нас и значительно уменьшило / устранило путаницу.

• Используйте обертку git, чтобы стимулировать прилипание рабочего процесса. Это то, над чем мы в настоящее время работаем, но мы поняли, что это совершенно необходимо для предотвращения простых и понятных ошибок, таких как ответвление от неправильного (недавно у нас была полная катастрофа, когда разработчик создал ветку темы из одноразового Ветка QA: эта тематическая ветка была одобрена для запуска, она была объединена... и куча изменений, которые не были одобрены для запуска, были добавлены). Наша оболочка git потребует подтверждения всякий раз, когда вы делаете что-то необычное (например, создаете ветку чего-либо, кроме master, создаете ветку без имени _NNNN, делаете коммит, который не начинается с _NNNN и т. д.). Иногда нам нужно делать эти вещи, так что оболочка не предотвращает это, но не дает людям случайно сделать что-то, чего они не должны.