Базовая логика работы с системой управления версиями на localhost + Mercurial

Question

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

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

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

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

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

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

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

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

Answer 1

Самый простой способ, если вы хотите редактировать свои файлы в ~/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" для того, чтобы переслать изменения в / reps, если вы хотите, чтобы они оставались синхронизированными.

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

Answer 2

Есть такие множество различных подходов / методов.Вот как я работаю:

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

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

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

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

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

Answer 3

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

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

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

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

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