Базовая логика работы с системой управления версиями на localhost + Mercurial
-
19-09-2019 - |
Вопрос
Я довольно новичок в Mercurial - на самом деле новичок в системе управления версиями.
У меня есть проекты на localhost, который называется ~/mamp/htdocs.Я хочу работать только на местном уровне.Есть один момент, который меня смущает:
Я думаю, что мне следует хранить репозиторий по другому пути, чем мои htdocs, поэтому я создал папку "/ reps /" и создаю папки для каждого проекта здесь, и копирую все файлы из папки проекта htdocs в reps.
например;проект01
копировать файлы из
~/mamp/htdocs/project01/
Для/reps/project01/
Но я работаю на localhost (htdocs) для изменения файлов и т.д.итак, как мне связать эти изменения с /reps/
?
Очевидно, я упускаю из виду какой-то очень очевидный момент, касающийся управления версиями.Неужели я неправильно начал?
Я думаю, что все учебные пособия, которые я нашел в Интернете, требуют каких-то базовых знаний;ни один из них ничего не говорит о значении нулевой точки!:/
Решение
Самый простой способ, если вы хотите редактировать свои файлы в ~/mamp/htdocs/project01/
(потому что я также согласен с тем, что было бы неплохо иметь какую-то промежуточную область, где вы могли бы протестировать свои изменения перед их развертыванием на рабочем сервере, но, возможно, промежуточной областью является именно ваш компьютер, так что тогда все в порядке :-)) является:
- Установите Mercurial
cd ~/mamp/htdocs/project01/
hg init
hg add *.html subdir *.css
(все, чем вы хотите управлять)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, если вы хотите, чтобы они оставались синхронизированными.
Надеюсь, это достаточно просто..
Другие советы
Есть такие множество различных подходов / методов.Вот как я работаю:
Развитие: Я проверяю (клонирую в случае mercurials) свои файлы в свою "среду разработки", чтобы поработать над ними, а затем зафиксировать / нажать / и т.д.в том же самом месте.
Следующие этапы: Как только я решу, что они готовы к пользовательскому тестированию / продакшн / или к любому другому вашему следующему этапу, тогда вы можете либо распространять свой код как
2а.пакет (может быть простым ZIP-файлом с вашими последними файлами) или
2б.проверьте их в каталоге следующего этапа.
Другие способы использования: Как только вы освоитесь с основными сценариями использования, вам следует рассмотреть другие способы контроля версий, такие как пометка, разветвление и слияние
Обычно вы должны хранить свою VCS (систему контроля версий) и ее файлы отдельно от среды вашего производственного веб-сервера (я полагаю, вы спрашиваете об этом, учитывая упоминание htdocs).
Во многих (по крайней мере, старых) веб-системах есть промежуточная область, куда вы копируете материал из исходной системы, который вы можете тщательно проверить, используя второй (не общедоступный) веб-сервер.Когда вы будете уверены в правильности кода, вы можете запустить его в производство.
Этот сценарий состоит из трех областей:
- Рабочая зона (разработка) с венчурными капиталистами и т. д;возможно, доступен через еще один веб-сервер).
- Промежуточная зона (без VCS, без публичного доступа;тестирование и валидация).
- Производственная зона (без VCS, открытый доступ).
Звучит немного так, как будто вы объединяете эти три фактора - обычный сценарий в моем ограниченном опыте.Даже если вы решите обойтись без промежуточной области, вам необходимо разделить ваши системы разработки и производства.А VCS (Mercurial) используется в рабочей зоне.