Базовая логика работы с Source Control на localhost + Mercurial - PullRequest
1 голос
/ 06 февраля 2010

Я довольно новичок в Mercurial - на самом деле новичок в управлении исходным кодом.

У меня есть проекты на localhost, а это ~ / mamp / htdocs. Я хочу работать на всех местных. Я запутался в одном:

Я должен держать репозиторий по другому пути, чем мой htdocs, я думаю, поэтому я создал папку "/ reps /" и создал здесь папки для каждого проекта, а также скопировал все файлы из папки проекта htdocs в повторы.

например; Проект01

копировать файлы из ~/mamp/htdocs/project01/ в /reps/project01/

Но я работаю на localhost (htdocs) для изменения файлов и т. Д. Так как мне связать эти изменения с /reps/?

Очевидно, я упускаю какой-то очень очевидный момент относительно контроля версий. Я сделал неправильный старт?

Все учебники, которые я нашел в Интернете, требуют каких-то базовых знаний; никто из них не говорит ничего из значения ноль! : /

Ответы [ 3 ]

4 голосов
/ 01 марта 2010

Самый простой способ, если вы хотите редактировать свои файлы в ~/mamp/htdocs/project01/ (потому что я также согласен, что было бы хорошо иметь некоторую промежуточную область, где вы могли бы протестировать свои изменения перед их развертыванием на рабочем сервере, но может быть, именно ваша машина является областью подготовки, так что тогда все в порядке :-)):

  1. Установить Mercurial
  2. cd ~/mamp/htdocs/project01/
  3. hg init
  4. hg add *.html subdir *.css (чем бы вы ни хотели управлять)
  5. hg commit -m"initial version"

После того как вы сделали hg init, в каталоге .hg в ~/mamp/htdocs/project01/ есть хранилище! Невозможно избежать этого (пока, по крайней мере) с помощью hg: если у вас есть источники в project01, вам нужно иметь репо в project01. И этого достаточно, потому что вы можете извлечь выгоду из контроля версий, просто всякий раз, когда вы изменяете файл, вы можете зафиксировать его и выдать сообщение журнала, чтобы сообщить системе, что вы сделали, например,

  • <edit> a.html
  • hg status (сообщит вам о текущих изменениях файлов)
  • hg diff (скажет вам отличия от сохраненной версии)
  • hg commit -m"what-has-changed-message" (сохранить новую версию)

Даже если нет необходимости иметь другое репо в другом месте (например, в / reps), если вы хотите , например, чтобы ваши данные были в резервной зоне, вы можете просто клонировать один в $ HOME:

  • cd /reps
  • hg clone /home/name/mamp/htdocs/project01/ project01

Который получит в /reps/project01 точную копию того, что вы сделали: все ваши изменения и все ваши сообщения журнала. Теперь, если вы сделаете это, всякий раз, когда вы делаете "hg commit", чтобы сохранить изменения в своем основном репо, вам также нужно сделать "cd /reps/project01" и "hg pull", чтобы переслать изменения в / повторы, если вы хотите, чтобы они оставались синхронизированными.

Надеюсь, это достаточно просто ..

1 голос
/ 06 февраля 2010

Обычно вы должны хранить вашу VCS (систему управления версиями) и ее файлы отдельно от среды вашего производственного веб-сервера (о чем я полагаю, вы спрашиваете при упоминании htdocs).

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

Этот сценарий имеет три области:

  • Рабочая (развивающая) зона с VCS и т.д .; возможно, доступен через еще один веб-сервер).
  • Зона подготовки (без VCS, без публичного доступа; тестирование и проверка).
  • Производственная площадь (без VCS, публичный доступ).

Звучит так, как будто вы объединяете эти три - общий сценарий в моем ограниченном опыте. Даже если вы решите обойтись без промежуточной области, вам необходимо разделить свои системы разработки и производства. И VCS (Mercurial) используется в рабочей области.

1 голос
/ 06 февраля 2010

Существует много разных подходов / методов . Вот как я работаю:

  1. Разработка: Я проверяю (клон в случае с Mercurials) свои файлы в моей «среде разработки» для работы с ними, затем фиксирую / нажимаю / и т.д. в том же месте.

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

    2a. пакет (может быть простой почтовый индекс ваших последних файлов) или

    2b. проверьте их в следующем каталоге.

  3. Другое использование: Как только вы освоитесь со сценариями основного использования, вам следует рассмотреть другие способы управления версиями, такие как маркировка , ветвление и слияние

...