Система контроля версий -> вопрос ветки

Я работаю над очередным заданием и вдруг понимаю, что мне нужно обсудить некоторые детали с моим начальником, чтобы продолжить. Я обсужу это через пару дней, когда встречусь с шефом. А пока мне нужно поработать над другой задачей.

Как правильно поступить?

Я вижу 2 варианта:

1) Скопируйте ревизию головы из репозитория в новую ветку и запустите там другую задачу. После того как закончу - сливаю в багажник. Или, может быть, мне нужно будет сначала выполнить слияние из транка в ветку, а затем слить обратно в транк?

2) Скопировать из рабочей копии в новую ветку. Вернуть ствол к последней ревизии (до того, как я начал задачу, которую мне нужно обсудить), переключиться на ствол и работать над другой задачей, затем закончить мою текущую задачу в ветке и слить.

Пожалуйста, подробно объясните правильный способ, так как я не являюсь опытным пользователем VCS. Заранее спасибо.


person nightcoder    schedule 07.09.2009    source источник
comment
Какую систему контроля версий вы используете? Теги указывают как svn, так и cvs.   -  person Greg Hewgill    schedule 07.09.2009
comment
Я думаю, что это не имеет значения, потому что вопрос общий, но я использую SVN   -  person nightcoder    schedule 07.09.2009
comment
Если это не имеет значения, используйте git stash :) kernel.org/pub/software/scm/git/docs/git-stash.html Серьезно, вы действительно можете использовать Git в качестве клиента Subversion с git svn и иметь все доступные функции облегченного управления ветвями Git. Я делаю это постоянно и не хочу отказываться от этого.   -  person Greg Hewgill    schedule 07.09.2009


Ответы (4)


Проблема, с которой вы столкнулись, заключается в том, что вы начали изменения в стволе, но хотите зафиксировать их в другом месте. Большинство систем контроля версий не имеют встроенного поведения для этого, что вызывает сожаление. В SVN лучше всего сделать следующее:

  1. Создать новую ветку от ствола
  2. Сделайте переключатель SVN, чтобы переключить текущую рабочую копию на эту ветку
  3. Теперь вы должны внести свои локальные изменения и иметь возможность зафиксировать их в новой ветке.
  4. После того, как вы зафиксируете их в ветке, сделайте еще один переключатель обратно в магистраль.
  5. Работа над новой функцией на багажнике
  6. После того, как вы обсудите детали с вашим начальником, объедините их с ветки обратно в ствол.

надеюсь, это поможет

person Arne Claassen    schedule 07.09.2009
comment
Должен ли я создать новую ветку из главной ревизии или из рабочей копии? - person nightcoder; 07.09.2009

На самом деле вам подойдут оба варианта, и ни один из них не является более правильным, чем другой; что будет определять самый простой способ действий, так это сложность, необходимая для слияния изменений. В общем случае в svn следует избегать слияния, если это возможно.

Обычно такое решение зависит от культуры вашей команды; если вашим коллегам обычно не нужны незавершенные/неутвержденные изменения в стволе, тогда имеет смысл переместить ваши изменения в ветку, а затем объединить после того, как ваш руководитель утвердит ваш код. Конечно, если вы работаете в одиночку, то все зависит от вас.

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

person Ken Liu    schedule 07.09.2009

Я выберу первый вариант, потому что я могу держать свой багажник в чистоте (работает постоянно). Поскольку функция, о которой вы говорите, еще должна быть подтверждена вашим боссом. Если эта функция в конечном итоге будет удалена, ваш ствол останется незатронутым, и другие члены вашей команды не будут сбиты с толку этими изменениями.

person NawaMan    schedule 07.09.2009

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

person JBrooks    schedule 07.09.2009
comment
Мы тоже так делаем... О, боль и страдания, которые это причиняет нам. Регрессов по лопате полно (т.к. багфикс делался в продакшн ветке для заказчика а не сливался в ствол). Циклы выпуска, которые растягиваются на вечность, потому что набор функций не может быть завершен вовремя, но уже частично зафиксирован в той же группе... с этого момента нет выбора... закончить то, что было начато в большой спешке, срезать углы, потратить следующее 3 месяца на стабилизацию и критику со стороны руководства из-за позднего и нестабильного релиза... прицел - person Newtopian; 07.09.2009
comment
У нас были те же проблемы, поэтому мы создали инструмент менеджера релизов, releasemanager.com. легко дергать функцию и контролировать то, что есть в выпуске. - person JBrooks; 07.09.2009