Отделение кода Dev от кода Live - PullRequest
1 голос
/ 01 апреля 2011

Довольно плохо знаком с использованием Mercurial и немного сбит с толку относительно хорошего подхода к отделению живого кода от кода разработчика. Я пришел от использования PureCM, где все было разделено на потоки, и вы можете просто объединить один поток с другим. Моя цель - настроить что-то в Mercurial, которое ведет себя аналогично.

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

Какие существуют подходы и какая документация о том, как это делается?

Ответы [ 3 ]

2 голосов
/ 01 апреля 2011

Филиалы - это то, что вы хотите. Вы можете создать стабильную ветку и ветку dev (и любые другие ветки, которые вам могут потребоваться) и объединить любые изменения из ветки dev в стабильную, когда считаете нужным.

Например, скажем, у вас есть репо без веток (кроме стандартного), и вы хотите ветку dev и стабильную ветку. Первое, что вы делаете, это создаете ветку dev

hg branch dev

Теперь ваша рабочая копия находится на ветке dev, а любые сделанные вами коммиты будут на dev. Если вы наберете hg branches, теперь должно появиться

dev
default

Для возврата к типу ветки по умолчанию hg up default

И, наконец, если вы хотите объединить изменения из ветви dev в default, введите

hg up default # update to the default branch
hg merge dev # merge changes from dev into working copy (default in this case)

Если ваш репозиторий опубликован с использованием hgweb , вы также можете увидеть хороший график коммитов и веток там.

0 голосов
/ 01 апреля 2011

Ознакомьтесь с учебником hginit.com - он охватывает некоторые стандартные стратегии.

У нас есть отдельные репозитории, у нас будет репозиторий поддержки prod и репозиторий dev. Изменения обслуживания в поддержке prod объединяются в dev.

0 голосов
/ 01 апреля 2011

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

Звучит так, как будто вы, возможно, больше боретесь с тем, как работает распределенный контроль версий. Это одно из фундаментальных отличий между распределенным и нераспределенным управлением исходным кодом (и, на мой взгляд, одним из главных преимуществ, которые оно дает вам).

Поскольку вы не связаны с центральным репозиторием, ваш «живой» код является просто еще одним клоном любого конкретного репозитория. Технически говоря, все клоны, которые вы делаете из любого кода распределенной системы контроля версий, который вы имеете, считаются «ветвью» (которая может быть или не быть похожей на потоки из PureCM, хотя у меня есть ощущение, что они похожи). Тем не менее, если у вас есть центральный репозиторий, из которого извлекают все ваши разработчики, все, что вам нужно сделать, это просто клонировать копию своего кода в любой момент, когда вы собираетесь с ним жить, и это ваша живая «ветка». Таким образом, ваши разработчики продолжают работать с самым последним кодом и сливаются с самым последним, и у вас есть целый репозиторий, представляющий собой только тот код, который вы получили.

Столь длинная история сделана длинной, это просто очередной клон. Это имеет смысл?

В качестве дополнительного примечания / примера того, как мой текущий рабочий процесс идет с одним из моих проектов, мы используем наш «центральный» репозиторий DVCS в качестве места, где идет дополнительный клон. Итак, у нас есть наше основное «приложение», из которого все тянут, и затем у нас есть «app-release-1-1-11» (который включает в себя дату, когда он был запущен). Так что выпущенный код также доступен на центральном репо. Надеюсь, это поможет!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...