Мы используем Mercurial на работе уже пару месяцев. Мы изменили наш рабочий процесс несколько раз и получили следующее:
Начальный снимок был на постановке , затем мы клонировали его в наш центральный репозиторий , и все клонировали, что локально .
- Когда мы работаем над функцией / исправлением, мы всегда обновляем последнюю стадию по умолчанию, чтобы начать с последней рабочей копии.
- Затем мы перемещаем ветвь функций в центральное хранилище для резервного копирования, делая его доступным для команды и т. Д.
- Мы заходим в нашу систему контроля качества, вытягиваем ветку функций и объединяем ее там.
- Если QA подписывает функцию, мы объединяем ее в стабильную ветвь на той же машине.
- Затем мы переводим стабильную ветвь в стадию, объединяем ее и проводим итоговое тестирование.
- Если все хорошо, мы передаем все в живую систему.
Это какое-то время работало для нас, но все еще есть грубое пятно, которое заставляет нас идти: "Мммм, может быть, есть лучший способ, это не совсем естественно" .
Самая большая проблема, которую мы имеем, это когда у нас есть ветка функций, которая стареет на нашей локальной машине.
Пример: * 1 034 *
- В моей системе есть ветка 62_EpicNewFeature.
- Приоритеты были реорганизованы, работа над EpicNewFeature прекращается: (
- 6 месяцев спустя я наконец возобновил работу над EpicNewFeature
На данный момент эта ветвь отстает от текущего значения по умолчанию. Если я закончу это и попытаюсь объединить это на QA , я получу так много конфликтов (для которых вы почти всегда сохраняете то, что сейчас на QA.)
Что мы иногда делаем, чтобы смягчить эту проблему, так это объединить default по умолчанию с EpicNewFeature, чтобы сделать его «быстрым». Это упрощает наше слияние в QA, но обычно это все еще чертовски локальное слияние.
Я читал о перебазировании, которое должно помочь сделать следующее слияние быстрым, поскольку вы (насколько я понимаю) внедряете историю в середине, изменяя свою собственную историю.
Большинство мест, которые я читал о rebase, предупреждают вас не делать этого, если вы уже добавили свои ветки, и определенно нет, если кто-то, возможно, уже вытянул ваши изменения. Как вы можете убедиться в этом? мы часто закачиваемся в центральное хранилище для резервного копирования и обычно просто hg pull all.
Видите ли вы что-то, что поможет нам улучшить наш текущий рабочий процесс? Поможет ли нам перебазирование чаще?