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

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

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

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

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

Я на Mac, извините, если ничего из этого не применимо, но я использую Coda в качестве редактора кода и установил Git через порты (используя Porticus).

Если бы я все заново настроил, я бы сделал:

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

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

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

4. Загрузите и установите GitX 7-5

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

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

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

Я использую 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 - просто замените все на новую версию.

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

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

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

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

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

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

Вы спрашиваете «но я ищу конкретные примеры установок / рабочих процессов, которые люди используют для хранения истории версий отредактированных файлов на сайте 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.

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

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

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