SourceTree: обновление разработки и мастеринга, когда оба отстают от активной ветки

Я оказался в середине проекта, в котором пытались использовать подход git-flow для поддержки кода.

Поскольку стратегии git-flow не соблюдались в начале проекта, ветка develop отстает от последней ветки feature на несколько месяцев, а ветка master еще дальше отстает от ветки develop. Ветки feature- использовались как ветки для развертывания кода.

Теперь возникает вопрос: используя SourceTree, как лучше всего обновить ветки develop и master, чтобы они были точно такими же, как последняя ветка feature, которая использовалась для развертывания? Я не вижу ничего полезного в develop или master, так как они устарели и было внесено так много изменений, что кажется, что они оба должны быть полностью перезаписаны.


git atlassian-sourcetree git-flow
person mg1075    schedule 02.11.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Поскольку вам не нужны изменения из master или develop, самым простым решением будет полный сброс этих веток.

  1. Переключитесь на master, дважды щелкнув его на левой панели.
  2. Найдите последнюю фиксацию, которая была развернута в рабочей среде, в представлении «Журнал/История».
  3. Щелкните правой кнопкой мыши этот коммит и нажмите Reset current branch to this commit.
  4. В диалоговом окне подтверждения переключите раскрывающийся список Using mode на Hard - discard all working copy changes, затем нажмите OK.

И повторите процесс для develop.

Альтернативой было бы удалить ветки и создать их заново.

  1. Щелкните правой кнопкой мыши ветку master на левой панели.
  2. Нажмите Delete master.
  3. В диалоговом окне подтверждения, если в ветке есть неслитые изменения, установите флажок Force delete, затем нажмите OK.

Повторите процесс для develop.

Затем возьмите любую ветку feature-*, которая использовалась для производственных развертываний, и переименуйте ее в master:

  1. Щелкните правой кнопкой мыши соответствующую ветку feature-*.
  2. Нажмите Rename feature-*....
  3. Введите master и нажмите OK.

Если у вас есть другая ветка feature-*, которая использовалась для разработки, сделайте то же самое, чтобы переименовать ее в develop.

Основное отличие здесь в том, что у вас больше не будет feature-* веток, которые могут быть, а могут и не быть тем, что вам нужно.

Влияние на историю

Предположим, ваша история выглядела примерно так:

... A--B [master]
   /
  *--*--*--C--D [develop]
         \
          *--* ... *--*--* [feature-1] (should be develop)
                  \
                   *--*--* [feature-2] (should be master)

После выполнения приведенных выше инструкций ваша история будет выглядеть так:

... A--B
   /
  *--*--*--C--D
         \
          *--* ... *--*--* [develop, feature-1]
                  \
                   *--*--* [master, feature-2]

(Где feature-1 и feature-2 могут больше не существовать в зависимости от того, какое решение вы выбрали.)

Когда вы перемещаете или удаляете ветку, коммиты не удаляются сразу. Таким образом, коммиты A, B, C и D все еще существуют, просто у вас нет простого способа добраться до них. Через некоторое время эти коммиты будут удалены Git сборщиком мусора, поэтому не забудьте добавить туда ветку или тег, если хотите их сохранить.

person Scott Weldon    schedule 02.11.2016
comment
Таким образом, опция полной перезагрузки равнозначна удалению старого кода в master? - person mg1075; 03.11.2016
comment
@ mg1075 Да, в основном. Обновлен мой ответ, чтобы уточнить. - person Scott Weldon; 03.11.2016