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