Ответ 1

Эрик Санк имеет отличную об основах управления версиями. Его компания (SourceGear) создает средство управления версиями под названием Vault, но практическое поведение в целом является довольно системным агностиком.

Ответ 2

• Не редактируйте свой код при создании.
• Создайте среду разработки с соответствующими службами (apache w/mod_php).
• Каталог приложений в среде вашего разработчика - это место, где вы выполняете свою работу.
• Поместите свое текущее производственное приложение там.
• Перенесите этот каталог в средство управления исходным кодом. (теперь у вас есть заполненный контроль источника с вашим приложением)
• Внесите изменения в новую среду разработки, нажав F5, когда вы хотите увидеть/проверить, что вы изменили.
• Слияние/фиксация изменений в исходном элементе управления.

Ответ 3

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

Таким образом, все файлы, которые не были извлечены, будут помечены как "только для чтения", если вы используете VSS (не уверены в SVN, CVS и т.д.). Таким образом, вы все равно можете запустить свой сайт, нажав "F5", и он перезагрузит файлы, в которых они сейчас находятся. Если вы проверите его и отредактируете, он будет НЕ читаться, и вы можете его изменить.

Независимо от того, что веб-сервер, на котором вы работаете, загрузит файлы с возможностью чтения/записи с тем же эффектом.

Ответ 4

У вас все еще есть файлы на жестком диске, готовые к F5!

Разница в том, что вы можете "перехватить" свои файлы в репозитории. Ваша повседневная жизнь не должна меняться вообще.

Ответ 5

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

Ответ 6

Это очень открытый вопрос, потому что, как вы используете SCM, в значительной степени зависит от того, какой SCM вы выберете. Распределенный SCM, такой как git, работает совсем по-другому от централизованного, такого как Subversion.

svn проще переварить для "нового пользователя", но git может быть немного более мощным и улучшить ваш рабочий процесс. Subversion также имеет отличные документы и поддержку инструментов (например, trac) и онлайн-книгу, которую вы должны прочитать:

http://svnbook.red-bean.com/

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

edit: Позвольте мне указать, почему люди на вас хмурят, кстати: SCM - это не просто "резервная копия вашего кода". Наличие "timemachine" не похоже на SCM. С помощью SCM вы можете вернуться в историю изменений и посмотреть, что вы на самом деле изменили, и когда это то, что вы никогда не получите с блоками кода. Я уверен, что вы спрашивали себя не один раз: "Как этот код пришел сюда?" или "Я думал, что я исправил эту ошибку" - если вы это сделали, вот почему вам нужен SCM.

Ответ 7

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

Вы просто используете файлы, как обычно. Только при управлении версиями, как только вы достигнете определенного состояния "завершено" или, по крайней мере, "работаете" (решите проблему в своем трекеру проблем, закончите определенный метод, измените что-нибудь и т.д.), Вы проверите его.

Если у вас более одного разработчика, работающего над вашей кодовой базой, обязательно обновляйте его регулярно, поэтому вы всегда работаете с недавней (объединенной) версией кода.

Ответ 8

Вот общий рабочий процесс, который вы будете использовать с нецентрализованной системой управления версиями, такой как CVS или Subversion. Сначала вы импортируете свой текущий проект в так называемый репозиторий - хранилище с версией всех ваших файлов. Будьте внимательны только для импорта файлов, созданных вручную (исходные файлы, файлы данных, файлы make файлов, файлы проектов). Сгенерированные файлы (объектные файлы, исполняемые файлы, сгенерированная документация) не должны помещаться в репозиторий.

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

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

Ответ 9

Отличный вопрос. С контролем источника вы все равно можете выполнить процесс обновления "F5". Но после каждого редактирования (или нескольких небольших изменений) вы хотите проверить свой код, чтобы у вас была резервная копия.

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

Ответ 10

Я бы рекомендовал систему управления распределенной версией (mercurial, git, bazaar, darcs), а не централизованную систему управления версиями (cvs, svn). Они намного проще в настройке и работе.

Попробуйте mercurial (это VCS, который я использовал, чтобы понять, как работает управление версиями), а затем, если вам нравится, вы даже можете перейти на git.

Там действительно хороший вводный учебник на домашней странице Mercurial: Понимание Mercurial. Это познакомит вас с основными концепциями VCS и тем, как все работает. Это действительно здорово. После этого я предлагаю вам перейти к учебникам Mercurial: Страница руководства по Mercurial, которая научит вас, как на самом деле использовать Mercurial. Наконец, у вас есть бесплатная книга, которая действительно отличная ссылка на использование Mercurial: Распределенный контроль версий с Mercurial

Если вы чувствуете себя более предприимчивым и хотите начать с Git сразу, то эта бесплатная книга - отличное место для начала: Git Магия (очень легко читается)

В конце, независимо от того, какой инструмент VCS вы выберете, то, что вы закончите, будет следующим:

• Имейте репозиторий, который вы не редактируете вручную, это только для VCS
• Создайте рабочий каталог, где вы внесете изменения, как обычно.
• Измените то, что вам нравится, нажмите F5 столько раз, сколько пожелаете. Когда вам нравится то, что вы сделали, и думаете, что хотите сохранить проект так, как он есть в тот самый момент (так же, как вы делали бы, когда вы, например, пишете что-то в Word), вы можете затем зафиксировать свои изменения в хранилище.
• Если вам когда-нибудь понадобится вернуться в определенное состояние вашего проекта, у вас теперь есть возможность сделать это.

И это в значительной степени.

Ответ 11

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

Ответ 12

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

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

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

Проверка/фиксация одного файла за раз была бы затруднительной.

Ответ 13

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

Если вы используете Subversion здесь хороший учебник.

Ответ 14

Система управления версиями, как правило, является местом хранения ваших файлов и их истории и обычно отделена от файлов, в которых вы сейчас работаете. Это немного зависит от типа системы управления версиями, но предположим, что вы используете что-то вроде CVS (например, подрывную деятельность), тогда все ваши файлы будут жить в двух (или более) местах. У вас есть файлы в вашем локальном каталоге, так называемая "рабочая копия" и одна в репозитории, которые могут быть расположены в другой локальной папке или на другом компьютере, обычно доступном по сети. Обычно после первого импорта ваших файлов в репозиторий вы проверяете их в рабочей папке, где вы продолжаете работать над ними. Я предполагаю, что это будет папка, в которой теперь находятся ваши PHP файлы.

Теперь, что происходит, когда вы проверили копию, и вы сделали некоторые нетривиальные изменения, которые вы хотите "сохранить"? Вы просто переносите эти изменения в своей рабочей копии в систему управления версиями. Теперь у вас есть история ваших изменений. Если вы в любой момент захотите вернуться к версии, в которой вы совершили эти изменения, то вы можете просто вернуть рабочую копию в более раннюю версию (имя, указанное для набора изменений, которые вы совершаете одновременно).

Обратите внимание, что все это очень специфично для CVS/SVN, так как GIT будет работать несколько иначе. Я бы посоветовал начать с подрывной работы и прочитать первые несколько очень отличных SVN Book, чтобы вы начали.

Ответ 15

Все это очень субъективно в зависимости от решения управления версиями, которое вы решили использовать. Тот, который вы обязательно захотите изучить, - это Subversion.

Вы упомянули, что вы делаете PHP, но делаете ли вы это в среде Linux или Windows? Это не очень важно, но то, что я обычно делал, когда работал в среде PHP, было иметь производственную ветвь и ветвь развития. Это позволило мне настроить задание cron (запланированное задание в Windows) для автоматического вытягивания из готовой к выпуску ветки для производственного сервера, а также вытащить из ветки разработки для моего dev-сервера.

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

Конечно, я заявляю, что все это не "возилось" годами. Я занимаюсь профессиональным развитием в течение некоторого времени, и мои методы могут быть излишними для кого-то на вашем месте. Не сказать, что с этим что-то не так.

Ответ 16

Я просто хочу добавить, что система, которую я считаю самой простой в настройке и работе, была Mercurial. Если вы работаете один, а не в команде, вы просто инициализируете его в своей обычной рабочей папке, а затем продолжаете оттуда. Обычный поток - отредактировать любой файл, используя ваш любимый редактор, а затем проверить (зафиксировать). Я не пробовал GIT, но я предполагаю, что он очень похож. Монотону было немного сложнее начать. Это все распределенные системы управления источником.

Ответ 17

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

Вот некоторые общие рекомендации, не относящиеся к веб-сайтам:

• Используйте локальную копию для разработки изменений.
• Скомпилируйте (если применимо) и проверьте свои изменения перед тем, как проверить
• Выполнять автоматические сборки и тесты как можно чаще (по крайней мере ежедневно)
• Версия вашей ежедневной сборки (есть способ указать точные биты кода, соответствующие конкретной сборке и тестовому прогону)
• Если возможно, используйте отдельные ветки для основных выпусков (или есть ветка разработки и выпуска).
• При необходимости стабилизируйте свою базу кода (определите набор тестов таким образом, чтобы прохождение всех этих тестов означало, что вы достаточно уверены в качестве своего продукта для его выпуска, а затем двигаетесь в сторону 0 ошибок тестирования, то есть запрещайте любые проверки релиз, кроме исправлений для нерешенных проблем).
• Когда у вас есть сборка, которая имеет нужные функции и прошла все необходимые тесты, разверните ее.

Если у вас небольшая команда, стабильный продукт, быстрый сбор и эффективные высококачественные тесты, то весь этот процесс может быть на 100% автоматизирован и может состояться через несколько минут.

Ответ 18

Я рекомендую Subversion. Настройка репозитория и его использование на самом деле довольно тривиальны даже из командной строки. Вот как это пойдет:

, если вы не настроили репозиторий (репозиторий)

1) Убедитесь, что на вашем сервере установлена ​​Subversion

$ which svn
/usr/bin/svn

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

1b) Если нет, получите

$ apt-get install subversion

apt-get - это инструмент, который устанавливает другие инструменты в вашу систему.

Если это не правильное имя для subversion в apt, попробуйте это

$ apt-cache search subversion

или

$ apt-cache search svn

Найдите правильное имя пакета и установите его, используя apt-get install packagename

2) Создайте новый репозиторий на своем сервере

$ cd /path/to/directory/of/repositories
$ svnadmin create my_repository

svnadmin create reponame создает новый репозиторий в текущем рабочем каталоге (pwd) с именем reponame

Вы официально создали свой репозиторий

, если у вас есть существующее репо, или закончили настройку

1) Убедитесь, что Subversion установлена ​​на вашем локальном компьютере в соответствии с инструкциями выше

2) Проверьте репозиторий на локальном компьютере

$ cd /repos/on/your/local/machine
$ svn co svn+ssh://www.myserver.com/path/to/directory/of/repositories/my_repository

svn co - это команда, которую вы используете для проверки репозитория

3) Создайте исходную структуру каталогов (необязательно)

$ cd /repos/on/your/local/machine
$ cd my_repository
$ svn mkdir branches
$ svn mkdir tags
$ svn mkdir trunk
$ svn commit -m "Initial structure"

svn mkdir запускает обычный mkdir и создает каталог в текущем рабочем каталоге с именем, которое вы указываете после ввода svn mkdir, а затем добавляет его в репозиторий.

svn commit -m "" отправляет ваши изменения в репозиторий и обновляет его. Независимо от того, что вы помещаете в кавычки после -m, это комментарий для этого фиксации (сделайте это посчитайте!).

"Рабочая копия" вашего кода будет находиться в каталоге соединительной линии. ветки используются для работы над отдельными проектами вне ствола; каждый каталог в ветких - это копия соединительной линии для другого субпроекта. теги используются больше выпусков. Я предлагаю просто сосредоточиться на багажнике на некоторое время и привыкнуть к Subversion.

работа с вашим репо

1) Добавить код в ваш репозиторий

$ cd /repos/on/your/local/machine
$ svn add my_new_file.ext
$ svn add some/new/directory
$ svn add some/directory/*
$ svn add some/directory/*.ext

Вторая в последнюю строку добавляет каждый файл в этот каталог. Последняя строка добавляет каждый файл с расширением .ext.

2) Проверьте статус вашего репозитория

$ cd /repos/on/your/local/machine
$ svn status

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

3) Обновить локальную копию вашего репозитория

$ cd /repos/on/your/local/machine
$ svn up

Обновление вытаскивает любые новые изменения с сервера, который у вас еще нет.

svn up не заботится о том, в каком каталоге вы находитесь. Если вы хотите обновить весь ваш репозиторий, убедитесь, что вы находитесь в корневом каталоге репозитория (над стволом)

Это все, что вам действительно нужно знать, чтобы начать. Для получения дополнительной информации я рекомендую вам проверить Subversion Book.