Mercurial и веб-сайты: когда делать ветки, когда клонировать?

Недавно мы решили начать использовать программное обеспечение SCM (да, наверное, давно пора было это сделать) и решили попробовать Mercurial. Из того, что я могу найти, он предположительно работает лучше с Windows, чем с Git. Мы также планируем использовать TortoiseHG вместо командной строки, так как это нам удобнее. Я все еще очень рано учусь, и у меня есть вопрос, на который я продолжаю находить противоречивые ответы.

У нас есть PHP-сайт, обслуживаемый Apache. Мы планируем разместить рабочую копию каждого разработчика на другом порту до тех пор, пока в будущем мы не сможем должным образом виртуализировать сервер (по одной на каждого разработчика). Мы хотели бы сохранить ветку/тег/что-то для «стабильной» сборки, пока мы продолжаем новую разработку. Конечно, всякий раз, когда есть исправление, мы хотим немедленно отправить его, но мы также хотим объединить его с веткой разработки.

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

Я также слышал, что мы должны просто использовать ветки и объединять ветки обратно, когда закончим.

В случае репозитория, что вы делаете с apache? Было бы неудобно перенастраивать его так, чтобы он указывал на другой каталог каждый раз, когда вы добавляете новые функции...

Спасибо за любой свет, который вы, ребята, можете пролить на это. Я ценю помощь!

Как нам это сделать?

[править] Кроме того, что такое «полка» и «патч» в отношении HG? Двойное спасибо.


person DOOManiac    schedule 11.07.2012    source источник
comment
У каждого разработчика есть своя клонированная копия (или даже несколько), и они отсылают изменения обратно в центральный репозиторий. было бы неудобно перенастраивать его так, чтобы он указывал на другой каталог каждый раз, когда вы добавляете новые функции... --- вы можете начать с каталога для каждого пользователя и перейти к некоторым автоматическим сценариям в будущем.   -  person zerkms    schedule 11.07.2012
comment
Да, я знаю эту часть. Мы планируем иметь рабочие каталоги для каждого разработчика, и каждый из нас получит порт в apache (2112 для одного пользователя, 2113 для другого и т. д.). Я работаю с фанатами Rush. Но мое понимание клонирования репозитория заключается в том, что это создает еще один каталог в вашей собственной рабочей папке, и поэтому мне нужно будет перенаправить мой апач с /blah/doomaniac/ на /blah/doomaniac-unstable/ или что-то еще?   -  person DOOManiac    schedule 11.07.2012
comment
Но мое понимание клонирования репозитория --- вам, вероятно, нужно изучить основы mercurial и попробовать с ним работать. Пока вы планируете свою работу, но все еще не понимаете, как работают выбранные вами инструменты.   -  person zerkms    schedule 11.07.2012


Ответы (1)


В распределенной системе контроля версий нет центрального сервера, каждый "клон" имеет копию целый репозиторий. Изменения вносятся в локальное репо, а более поздние наборы изменений передаются в другие (или извлекаются из них). Итак, на практике каждый клон — это ветка, а каждый «коммит» — это слияние.

Ниже я предложу пример рабочего процесса. Для более подробного объяснения того, что я написал, см. эту статью (Изменить: на самом деле я имел в виду этот, об управлении релизами, но другой тоже полезен...) и этот краткий обзор Mercurial.

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

Вы также можете клонировать его снова для каждого разработчика (повторяю: вы клонируете только один раз) и заставить их работать независимо друг от друга. Они могут фиксировать по желанию (поскольку фиксация влияет только на локальный репозиторий) и в идеале должны отправлять наборы изменений в «основной» только тогда, когда они стабильны. Они также могут получать наборы изменений от других разработчиков, но им решать, выполнять слияние немедленно или нет. Когда «основной» выпуск имеет стабильную версию, он должен быть помечен как таковой, и «производственный» может получить и обновить эту версию.

Если в производственной версии обнаружена ошибка, любой разработчик может: а) зафиксировать (или отложить) свой текущий рабочий каталог; б) обновить свой рабочий каталог до той же версии, что и «производство»; c) исправить ошибку, зафиксировать и отправить изменения; г) снова обновиться до того места, где он ушел, и продолжить работу в обычном режиме. Новый набор изменений будет доступен для «производства» для извлечения и обновления, а также для каждого разработчика, чтобы объединить его со своей текущей версией.

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

person mgibsonbr    schedule 11.07.2012
comment
Я читал hginit.com (hginit.com/05.html) и примерно на полпути, это где Джоэл говорит о создании клонов репозиториев (оба будут принадлежать разработчику) для написания новых функций, а затем обратного слияния со своим собственным репозиторием. (Это позже переносится в другие репозитории). Вот что я имел в виду, когда говорил о клонировании. Это разумный поступок или лучше ветвление? Спасибо за все ссылки, обязательно прочту. (Извините, что не прочитал их перед ответом; уже поздно, и я пошел спать) - person DOOManiac; 11.07.2012
comment
Без проблем! Тем не менее, я не могу дать вам короткий ответ. Ссылки, которые я предоставил, пытаются сделать именно это: объяснить обоснование каждого инструмента. Многие рабочие процессы могут работать, и ваш мне кажется вполне подходящим. Важно отметить, что вам не нужно часто клонировать (как в hg clone), и если ваша установка требует фиксированного каталога для каждого разработчика, это единственное клонирование, которое вам нужно сделать. Вместо этого вам нужно будет часто нажимать/вытягивать/обновлять, и TortoiseHg очень помогает организовать это (инструмент Workbench показывает хороший график разветвлений и слияний, выделяет помеченные ревизии и т. д.). - person mgibsonbr; 11.07.2012