Методология управления предпочтительной версией

Я делаю все свои разработки в багажнике. Я один разработчик и не хочу иметь дело с проблемами ветвления. Когда мой код стабилен, я просто отмечаю текущую версию. Например, я бы пометил версии 1.0, бета-версию 2.0, версию-кандидата 2.0, версию 2.0 и т. Д. Вероятно, ветвление будет лучшей альтернативой, если вы поддерживаете старые версии для исправления ошибок и поддержки, но так как я этого не делаю, я не надену не беспокойся об этом.

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

С мерзавцем, переходя и объединяясь практически легко, таким образом, это - общий рабочий процесс для меня, чтобы содержать мое ведущее устройство в чистоте и сделать всю мою работу в ответвлениях. Ветвление и слияние в svn, особенно в предыдущих версиях, не являются вполне настолько дешевыми и легкими, поэтому когда я использовал svn, я был склонен работать непосредственно над соединительной линией.

Всегда стабильно. Даже если я один разработчик - особенно если я одинокий разработчик.

Наличие сломанного дерева для меня означает еще один способ узнать, что я должен делать.

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

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

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

Я всегда использовал основную соединительную линию в качестве главы кода. Код вообще новой разработки идет туда.

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

, Когда мы делаем исправления ошибок, они входят в основном сначала, и затем они объединяются (бэкпортированные) в соответствующее ответвление версии при необходимости.

, Если большой эксперимент разрабатывает его объединенная спина get в основное.

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

Я нахожусь в для всегда стабильной соединительной линии. Необходимо быть в состоянии восстановить последнюю стабильную версию в любое время...

В вашем случае я бы настоятельно рекомендовал избегать большого количества ветвлений. Это действительно довольно продвинутый процесс и не обязателен для небольших проектов и небольших команд.

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

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

Один аспект - то, какой длины изменения будут в нестабильном состоянии.

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

то, Когда изменения я делаю, не будет влиять на других людей (потому что это - мой частный код дома, вместо того, чтобы кодировать на работе), тогда я соглашаюсь с регистрацией в нерабочих промежуточных состояниях, если это - то, что я хочу. Иногда, я сделаю несколько checkins подряд, которые не стабильны; это хорошо для меня, когда это - просто я, кто затронут, и рабочий процесс будет непрерывен. Это - если я возвращаюсь через несколько лет (в противоположность всего нескольким дням), и вещи не работают, что это становится проблематичным (один недостаток того, чтобы быть вокруг, пока я имею - у меня действительно есть некоторые проекты, которые находятся все еще в разработке и обслуживании, которые являются достаточно взрослыми для голосования).

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

One key distinction is how big files tend to be on average. Big files (1000 lines +) tend to have many independent changes that are trivially automatically mergeable. So the fact that someone else is actively changing a file you are about to start work on is probably uninteresting, so it is ok if the system makes that hard to discover.

So you tend to end up a VC strategy that has a lot of branches, and easy merges. New functionality is written in new branches.

If you are working with the smaller, highly-cohesive files typical of an OO design, in a language like Java, such accidental conflicts are a lot rarer. Even as an artificial example, it is pretty hard to come up with two sets of changes that can be made to a class (and corresponding JUnit test cases) that can sensibly be made in isolation and then automatically weaved back together by a text merge tool.

If you do a lot of refactoring (renaming and splitting files) then that stresses out the merge tool even more.

So you tend to be best off with a VC strategy that has an identifiable and usable stable trunk and minimal branches.

In the first approach, new functionality is written in new branches, and merged when complete. In the second, it is written in new files, and enabled when complete.

Of course, if you do the second, you definitely need strong protection from the baseline becoming unusable for any length of time (i.e. continuous integration and a strong automatically-run test suite).