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

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

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

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

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

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

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

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

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

ОБНОВЛЕНИЕ:

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

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

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

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

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

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

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

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