it-swarm.xyz

Начало работы с Subversion, Git или аналогичной системой контроля версий, чтобы хранить историю моих файлов?

Я понимаю, что это может быть широким вопросом на первый взгляд, но я ищу конкретные примеры установок/рабочих процессов, которые люди используют для хранения истории версий отредактированных файлов на сайте WordPress. Например, при разработке сайта (и даже после его открытия) я часто вносю изменения в файлы CSS и PHP, но у меня нет отличного способа вернуться к более старым версиям этих файлов. В моих целях внесение изменений в локальную установку разработки и последующее копирование этих изменений на работающий сайт часто доставляет больше хлопот, чем мне бы хотелось. Любые предложения о том, как начать использовать инструмент управления версиями для отслеживания изменений в файлах на реальном сайте?

31
Travis Northcutt

Я не уверен, сколько вы знаете об использовании контроля версий, но я недавно переключился с SVN на GIT и считаю, что это здорово!

Хотя это зависит от того, установлен ли на вашем сервере живого сайта GIT (или позволит вам). У меня также есть настройка GIT на живом сервере, на которой работает ветка, которая называется что-то вроде production. Всякий раз, когда я заканчиваю реализацию/исправление чего-то локально, я объединяю это с веткой production, затем SSH с сервером живого сайта и вносим изменения. Превышение перетаскивания файлов по FTP, когда вы никогда не знаете, перезаписываете ли вы изменения и т.д.

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

Так:

Конечно, я на Mac, извините, если ничего из этого не применимо.

Редактор кода: Coda Установил GIT через порты (используя Porticus) Git: GitX

Если бы я все настроил по-новому, я бы сделал:

  1. Установить Coda

  2. Установить Porticus (для этого потребуется установить порты, но на этой странице есть информация)

  3. После того, как вы установили Porticus, откройте его, найдите "git-core" и установите его.

  4. Скачать и установить GitX 7-5

  5. Существует хорошее руководство по настройке git-репо здесь , но в его основе: 1. Откройте Терминал. 2. cd туда, где вы хотите разместить свой сайт. $: mkdir mysite && cd mysite 3. $: git init и это все! Если вы добавляете файлы в эту папку, переходите к следующему шагу

  6. Как только вы настроили GIT-репозиторий локально (см. Выше), тогда, если вы откроете этот каталог в GitX, вы сможете фиксировать что-то и т.д.

Настроить все это на сервере может быть немного сложно, у меня есть MediaTemple и учетная запись Dreamhost, которые оба имеют GIT из коробки. Ссылка в 5. рассказывает, как добавить удаленное репо, вам не нужно делать это, пока вы не захотите привести свой живой сайт в уравнение. Я бы порекомендовал, чтобы сначала все работало локально (в отличие от SVN, GIT не требует удаленного хранилища, поэтому вы можете пока что загружать все на своей машине)

14
Joe Hoyle

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

Плагины

Поскольку плагины уже размещены на сервере WordPress, я просто извлекаю плагин непосредственно в каталог /wp-content/plugins/ моей локальной установки WordPress (я запускаю WAMP на своем компьютере для разработки). Затем я делаю изменения в своей локальной копии и, когда она будет готова к показу, фиксирую в хранилище. Там все идет гладко, без выгрузки/загрузки и мгновенной проверки того, что мои изменения сработали.

Темы

Темы немного отличаются, особенно при создании для клиента. Я создаю локальный репозиторий (у меня есть раздел R на моем жестком диске специально для этой цели) и извлекаю пустой репозиторий прямо в мой каталог /wp-content/themes. Затем я делаю изменения по мере необходимости и развиваюсь до тех пор, пока он не будет готов, внося изменения по мере продвижения.

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

Инструменты

Как я уже сказал, я использую WAMP на своем локальном компьютере для запуска установочной установки WordPress. Он отлично работает на моем компьютере и позволяет мне запускать столько экземпляров WordPress, сколько мне нужно для конкретного проекта.

Для SVN я использую черепаха SVN . Он бесплатный, удивительно простой в использовании и интегрируется со структурой файлов и команд Windows. Обновление, фиксация и экспорт - все это просто щелчок правой кнопкой мыши, выбор командных операций. Использование "Экспорт" позволяет отправлять всю папку (без надоедливых папок .svn) напрямую в любое место по вашему выбору - я часто экспортирую на рабочий стол. Архивирование папки также выполняется правой кнопкой мыши, а WordPress выполняет загрузку.

Передача файлов вручную может быть хлопотной, особенно если вы продолжаете изменять один файл, но не все. Если вместо этого вы используете FTP по всему каталогу с выбранным "перезаписать все", гораздо проще заменить старые файлы (и вам не нужно отслеживать, какие изменения были, а какие нет). Это похоже на старую 5-минутную установку WordPress - просто замените все на новую версию.

8
EAMann

Лично я считаю, что это забавное упражнение - установить SVN/GIT и управлять им, но если вы можете заработать $ 15 в месяц, Beanstalk стоит каждого пенни. Они управляют всем сервером за вас. http://beanstalkapp.com/ Инструменты развертывания FTP потрясающие. Мой автоматически развертывает версию на моем промежуточном сервере, когда я, например, фиксирую

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

Мы сохраняем нашу рабочую копию SVN в dropbox, затем я фиксирую файлы, когда наступит время записи. Мои дизайнеры не будут фиксировать файлы или иметь дело с SVN, так что это компромисс.

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

3
Andrew

Мне нравится Aptana много, в него встроена Subversion, и вы можете легко подключиться к вашему серверу с помощью ftp/sftp и Push-файлов, еще одна замечательная особенность, которую он имеет, заключается в том, что если вы создаете новый проект php и включаете "Вся" папка WordPress (с wp-admin, wp-includes) вы получаете завершение кода в файлах вашей темы.

В моей настройке репо локально.

2
Amit

Вы спрашиваете "но я ищу конкретные примеры установок/рабочих процессов, которые люди используют для хранения истории версий отредактированных файлов на сайте WordPress", но вы также упоминаете продукты :)

Вы получите выше, как ответ на список инструментов и некоторые лучшие практики, но я сосредоточусь здесь на рабочих процессах: ОНИ НЕ БЕСПОКОЙНЫЕ, СПЕЦИФИЧНЫЕ:

Но для общих примеров/настроек/рабочих процессов:

Для начала: есть шаблоны CM, которые не зависят от инструментов. Google on CM Patterns, много книг, даже вики-сообщества, например http://www.cmcrossroads.com/forums .

Существуют также руководства по настройке действующей стратегии потоковой передачи (стратегии потоковой передачи Google) и т.д.

Я не думаю, что есть что-то особенное в развертывании WordPress по сравнению с CM Management, включая распределенную параллельную разработку на крупных фабриках Siebel, SAP, Informatica, Java и т.д. Это действительно почти по умолчанию.

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

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

план CMP начинается с определения всех элементов конфигурации, другими словами: составьте список всех типов элементов конфигурации, присутствующих в реализации WordPress, включая приложения, плагины, базу данных, документацию, справку, содержимое, файлы конфигурации, заметки о выпуске (!) и т. д. ..). Это хорошее начало. Затем решите, какие из них вы хотите взять под CM.

Затем решите, что вызывает изменения в этих CI, например. вызов клиента для исправления ошибки или необходимого обновления. Если все сделано правильно, это приводит к ситуации, когда вы чувствуете, что все под контролем.

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

Только позже ищите инструмент для выполнения CM с одной стороны (который включает управление версиями в качестве одного из инструментов) и инструменты управления изменениями с другой стороны (что держит вас в здравом уме).

Я думаю, что это лучший рабочий процесс для начала, так как, насколько я гуглил, еще никто не сделал. Я думаю, что как только первый человек написал План WordPress CM (согласно IEEE), каждый второй человек в мире WordPress может скопировать этот план, внести коррективы и внедрить шаблоны в свои инструменты.

Разве это не слишком много работы/не слишком тяжело: зависит от того, есть ли у вас компания или нет: это может сэкономить вам время на то, чтобы иметь хороший план CM.

1
edelwater

Я на общем хосте, поэтому я не могу установить SVN или что-то подобное. Я использую Mercurial для контроля версий на моей домашней машине. Я использую FTP-синхронизацию Beyond Compare для синхронизации локальных и удаленных папок.

0
CAD bloke

я использую мерзавца это просто. Вы просто должны понимать простую команду, такую ​​как клон, комит, Push, Pull, и вы готовы к работе. это основное.

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

0
justjoe