Mercurial TortoiseHG - Как выровнять обновления между ветками?

Рассматривая проект в TortoiseHG с тремя ветвями ("поумолчанию", "Фаза 1", "Фаза 2"), возможно ли внести изменения в одну ветку и отразить их в одной или обеих других, не объединяя их?

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

Если так, как это сделано? Это синхронизация? От себя? Что-то другое?

Может ли кто-нибудь сказать мне, что нужно сделать, чтобы это произошло (при условии, что это выполнимо)?

Спасибо Сетнара

2 ответа

Решение

Да, это возможно, и я вижу как минимум 2 очевидных и одно приятное решение, но

НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ЯВНОЕ В БУДУЩЕМ И БЕСПЛАТНОМ ИСПРАВЛЕНИИ РАБОТЫ ПО БЕЗОПАСНОСТИ! НОЧЬ, ЧТОБЫ ОБРАЩАТЬСЯ С ТАКИМИ ПРОЕКТАМИ ПОЗЖЕ КОДЕКСА!!!


Rebase стиль

  • Перебазировать наборы изменений (hg help rebase), начиная с первого изменения исправления ошибок, на новые цели (главы филиалов) hg rebase -s $BUGFIX_START -d Phase 1 + hg rebase -s $BUGFIX_START -d Phase 2 (в предположении, что исправление является частью ветви по умолчанию), сохраняя перебазированные наборы изменений в исходной ветви hg rebase ... --keep
  • Разрешить возможные конфликты
  • Поскольку rebase перебазирует всех потомков $BUGFIX_START, возможно, с некоторыми наборами изменений, не связанными с исправлением ошибок, hg strip не-исправления изменений из адресатов rebase

Прививка стиль

  • Прививка (hg help graft) позволяют вводить отдельные наборы изменений из одной части дерева в другую (в отличие от rebase, который внедряет поддерево из пользовательского узла или слияние, которое внедряет всю историю от наибольшего общего предка). Ты должен:
    • обновить до целевой ветки (hg up Phase 1), читать hg help update
    • выбрать все необходимые наборы изменений и перечислить в rebase (см. -r варианты команды) hg graft -r $BUGFIX_START -r $BUGFIX2 ... -r $BUGFIXN -D -U --log
    • выполнить два предыдущих шага с ответвлением Фазы 2

и, наконец,

"Правильный путь" (тм) - Именованная ветвь

  • Создайте именованную ветвь от точки или родителя для $ BUGFIX_START hg up $BUGFIX_START + изменить что-то + hg branch SEMANTICNAMEOFBUGFIX``hg ci -m "Branch for $BUGFIX"
  • Перебазировать (с зачисткой после, при необходимости и без --keep) исправления ошибок, связанных с этой новой именованной веткой
  • Объединить SEMANTICNAMEOFBUGFIX со стандартным, Фаза 1, Фаза 2
  • Всегда используйте "Branch Per Task" в будущем, остановите спагетти-чушь в коде и репозитории-истории

Я перевожу пучок неуважения к вашему наставнику: он должен был сказать и объяснить это, прежде чем разрешать публичные коммиты (локальный личный репозиторий может быть кошмаром в любой степени)

Я настоятельно рекомендую читать не только код, но и документацию, а также советы и советы от мудрых и опытных пользователей, чтобы не постоянно изобретать велосипед

Это само по себе невозможно. Слияние - это всегда один шаг, из-за возможных конфликтов, которые вы можете иметь. Они должны обрабатываться отдельно, по одному за раз.

Конечно, есть возможность иметь несколько клонов, уже обновленных в каждой ветви, если обновление является болезненным. Таким образом, вы можете пройти через них, чтобы объединить новую ветку исправлений...

Тем не менее, это типичная проблема, которую может помочь решить ваш процесс выпуска. Например, если default ваша исходная ветка и Phase1 а также Phase2 должны быть объединены в конце концов в defaultпочему бы не иметь default часто сливаются во всех других ветках? Instate политика слияния default часто в ветках разработки, это поможет разрешить конфликты раньше, чем позже, и они получат выгоду от случайного исправления ошибки, после того как она была объединена вdefault,

Если default это не ваша исходная ветвь, создайте новую ветвь, которая может содержать только исправления, и часто объединяйте эту ветку с вашими ветвями фазы, но вы получаете суть.

Другие вопросы по тегам