Базовый контроль версий для вопросов веб-разработки - Единый разработчик.(СВН / ГИТ) - PullRequest
2 голосов
/ 23 февраля 2012

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

Я провел немало исследований, и большинство уроков довольно продвинуты и кажутся мне не подходящими. По сути, я решил использовать SVN-репозиторий от beanstalk и Versions.app для работы с ним.

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

  • Действительно ли необходимо использовать типичную структуру SVN (ствол / ветви / метки)? Могу ли я не просто использовать репо в качестве веб-корня?

  • Как я могу извлечь выгоду из филиалов? Beanstalk рекомендует развертывание из веток. Насколько я понимаю, это может означать создание производственной ветви, а затем слияние с этой веткой из магистрали перед развертыванием? Есть ли причина не просто развертывать из Trunk или просто иметь webroot в SVN и развертывать его? Я полагаю, что я в основном спрашиваю, почему, будучи одним разработчиком, я хотел бы использовать ветви для разработки веб-сайтов?

  • Есть ли причина, по которой я мог бы извлечь выгоду из ЖКТ? Единственная главная особенность, которую я мог видеть при автономной фиксации, но beanstalk даже рекомендует SVN для файлов веб-разработки (html, php, изображений и т. Д.).

Любая помощь с благодарностью. Я давно хотел использовать систему контроля версий и разрабатывать в автономном режиме уже некоторое время. Надеюсь, больше не нужно редактировать живые серверы для меня! Я думаю, что правильный рабочий процесс в начале - это энергоемкий проект, но он того стоит в конце.

-

edit: я занимаюсь в основном WordPress веб-сайтами и различными проектами EE в достаточно небольших масштабах, ничего особенного.

-

edit: Как и все, работа с системой и ее опробование - единственный способ по-настоящему познакомиться с ней. В конце концов я выбрал Git. Я был очень рад тому, что смог быстро выполнить автономную фиксацию, выполнить быстрые ветки, объединить и т. Д. Затем развертывание с помощью capistrano, хотя и изначально сложным в настройке, было невероятным. Мой рабочий процесс теперь так фантастически улучшен. Я могу быстро добавлять новые функции и пробовать новые идеи. Я никогда не буду разрабатывать проект снова без мерзавца!

Ответы [ 3 ]

2 голосов
/ 23 февраля 2012

Я бы рекомендовал следовать стандартной структуре.Если позже вы привлечете других разработчиков и они знакомы со стандартной структурой, это будет намного проще.

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

Создание тега тривиально, а ценность, которую вы получаете от него, огромна.*

Я работаю над проектом только с двумя разработчиками в течение 18 месяцев, и мы еще не создали ветку.Я подозреваю, что вам также не понадобится их использовать, и вместо этого вы можете развернуть их из тегов выпуска.

1 голос
/ 24 февраля 2012

У вас действительно 4 вопроса

Действительно ли необходимо использовать типичную структуру SVN (ствол / ветви / метки)?

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

Могу ли я не просто использовать репо в качестве веб-корня?

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

Как я могу извлечь выгоду из Филиалов?

Отдельная линия разработки, которая:

  • не мешает основной линии
  • позволяет решить более одной задачипараллельно со строгим разделением изменений

Есть ли какая-то причина, по которой я мог бы извлечь выгоду из GIT?

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

1 голос
/ 23 февраля 2012

Я использовал SVN годами и до сих пор время от времени, но я постепенно переключаю свою команду на git. Git работает быстрее, более гибок и допускает локальные коммиты. Вы можете работать онлайн или офлайн. С git вы не делаетенужна структура папок для веток и тегов - вы просто говорите git branch или git tag, и он автоматически делает снимок вашего проекта. Есть плюсы и минусы как для svn, так и для git, но в целом я думаю, что мне понравится gitнемного лучше. Это также «новая вещь», так что вам может быть лучше учиться, когда вы в конечном итоге работаете с командами.где находится текущий код. Исправления ошибок и быстрые изменения идут туда. Разработка, которая займет больше, чем несколько часов, идет в ветке - для новых проектов, дополнений, для веб-сайта, над которым вы работаете. Как исправления ошибок и так далеествол, мы объединяем их обратно в нашу ветку, чтобы он имел последние исправления и незначительные изменения. Когда ветвь закончена, мы внедряем ее, делаем ееunk, и заархивировать старый багажник.Мы также помечаем все, что выпускаем, поэтому у нас есть снимок того, что было отправлено в производство.

Я мог бы заглянуть в частные репозитории на github, чтобы начать.Или вы можете просто работать локально с git, но приятно иметь удаленный сервер для резервного копирования или перенести что-то на другую машину.

...