Наша команда на работе с энтузиазмом приняла рабочий процесс rebase, но мы, возможно, немного увлеклись, и в этом суть этого вопроса: вы будете судьей.
Использование pull --rebase - этоПонятно для меня сейчас.Тем не менее, у нас также есть большие ветки, над которыми работают несколько человек.Периодически мы хотим внести изменения, которые происходят на мастере.Обычная мудрость заставила бы нас слиться, так как это общая ветвь.Тем не менее, в нашей навязчивой идее мы решили перебазировать эти ветви.Конечно, это требует сотрудничества каждого.Рабочий процесс выглядит примерно так:
1) Ребазер координирует свои действия со всеми, чтобы убедиться, что все они зарегистрированы и перенесены в ветку функций, а затем просит их больше не работать в этой ветке, пока ониполучить все ясно.
2) Ребазер перераспределяет ветвь функции на главную, удаляет удаленную ветку функции (git push origin: feature), а затем выдвигает новую перебазированную ветку функции (функция git push origin)
3) У ребазера есть все выборки, которые обновляют свою ветвь функций, затем удаляют их локальную ветвь функций (git branch -D feature), затем создают новую локальную ветвь функций, которая отслеживает удаленную ветвь функций.Затем каждый получает все ясно.
Этот рабочий процесс работает, частично потому, что мы небольшая группа, а рабочие прерывания небольшие.Однако меня беспокоит, что мы изучаем плохие привычки Git (перебазируем общую ветку) или что рабочий процесс не будет хорошо масштабироваться.
С другой стороны, история нашего репозитория прекрасна.
Как вы думаете, Git Gurus?Мы играем с огнем или качаем разумный рабочий процесс?
ОБНОВЛЕНИЕ :
Прошло два года с тех пор, как я изначально задал вопрос, и с тех пор мой рабочий процесс изменился,Мы все еще обычно делаем git pull --rebase, так что это не изменилось.Это здравый смысл, и он предотвращает все неприглядные, запутанные мини-слияния.(Мы держим в основном синхронизацию, поэтому git pull --rebase) не требует больших затрат.
Однако, кроме этого, и случайных героических действий по исправлению ошибки, мы преодолели наше безумие по поводу перебазирования.Слияние имеет смысл большую часть времени.Однако бессмысленное объединение проблематично и вносит свой вклад в запутанную хаотическую историю, о которой я беспокоился два года назад.
Наше решение состоит из нескольких компонентов:
Мастерветка "нетронутая".Ветви темы объединяются, и после этого ветка темы удаляется .Другими словами, объединение тематической ветви в означает, что эта работа готова к производству и теперь является частью основной ветви.Из истории наших версий становится ясно, что происходит: ветки тем объединяются в master, и все.
При необходимости мы используем одноразовые ветки интеграции.Например, если у нас есть ветки тем A, B и C, и ни одна из них не готова для интеграции в master, но нам нужно протестировать их вместе, мы просто создаем ветку QA (обычно не ведущую) и затем объединяемA, B и C in. В какой-то момент ветвь QA удаляется или используется повторно.Дело в том, что он никоим образом не должен быть постоянным и не имеет тех же ограничений, что и основная ветвь (вы можете объединять ветки тем столько раз, сколько захотите).Если история становится слишком запутанной, вы можете просто удалить ветку QA и начать все заново (подход, который мы нашли очень естественным).
При объединении всегда используйте git merge --no-ff.Это настолько грандиозное изменение нашей одержимости «историей линейных коммитов» двухлетней давности, что оно заслуживает комментариев.Теперь, когда мы расслабились в истории линейных коммитов и увидели, что слияния хороши и полезны, мы начали полагаться на ветки тем, которые фактические ветки вне мастера, а непросто серия коммитов, которая в итоге становится единым с мастером.git merge --no-ff гарантирует, что всегда есть коммит слияния, даже когда в этом нет необходимости.
У нас есть хорошо понятное соглашение для коммитов сообщений и веток и, что более важно, оно пересекается- ссылается на нашу систему отслеживания проблем .Наша система отслеживания ошибок использует числовые номера ошибок, и для любой функции (или дефекта) у нас есть номер проблемы (например, 1234).Если вы работаете над этой проблемой, вы должны создать ветку _1234 и начать каждое коммит-сообщение с "_1234: doing blah blah".Это может показаться немного навязчивым, но это действительно хорошо сработало для нас и значительно уменьшило / устранило путаницу.
Используйте оболочку git для поддержки адгезии рабочего процесса.Это то, над чем мы сейчас работаем, но мы поняли, что это абсолютно необходимо для предотвращения простых и понятных ошибок, таких как отделение от неправильной вещи (у нас недавно случилась полная катастрофа, когда разработчик создал ветку темы из одноразового использования).Ветвь QA: эта ветка темы была одобрена для запуска, она была объединена ... и куча преобразователей, которые не были одобрены для запуска, были засосаны).Наша оболочка git будет требовать подтверждения всякий раз, когда вы делаете что-то необычное (например, создание ветви из чего-либо, кроме master, создание ветви без имени _NNNN, создание коммита, который не начинается с _NNNN и т. Д.).Иногда нам нужно делать такие вещи, чтобы обертка не предотвращала этого, но не позволяла людям случайно делать то, что они не должны.