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

<p>я понимаю, что это может быть широким вопросом на первый взгляд, но я ищу конкретные примеры установок/рабочих процессов, которые люди используют для хранения истории версий отредактированных файлов на сайте wordpress. например, при разработке сайта (и даже после его открытия) я часто вносю изменения в файлы css и php, но у меня нет отличного способа вернуться к более старым версиям этих файлов. в моих целях внесение изменений в локальную установку разработки и последующее копирование этих изменений на работающий сайт часто доставляет больше хлопот, чем мне бы хотелось. любые предложения о том, как начать использовать инструмент управления версиями для отслеживания изменений в файлах на реальном сайте?</p>

<p>я не уверен, сколько вы знаете об использовании контроля версий, но я недавно переключился с svn на git и считаю, что это здорово!</p><p>хотя это зависит от того, установлен ли на вашем сервере живого сайта git (или позволит вам). у меня также есть настройка git на живом сервере, на которой работает ветка, которая называется что-то вроде <code>production</code>. всякий раз, когда я заканчиваю реализацию/исправление чего-то локально, я объединяю это с веткой <code>production</code>, затем ssh с сервером живого сайта и вносим изменения. превышение перетаскивания файлов по ftp, когда вы никогда не знаете, перезаписываете ли вы изменения и т.д.</p><p>я бы порекомендовал потратить некоторое время на ознакомление с git (если вы этого еще не сделали), я считаю, что это намного проще и менее хлопотно, чем svn, когда дело доходит до изменения/добавления множества файлов (и в отличие от svn это не делает глупостью). папка <code>.svn</code><em> везде </em>).</p><p>так:</p><p>конечно, я на mac, извините, если ничего из этого не применимо.</p><p>редактор кода: <a href="http://www.panic.com/coda/">coda</a> установил git через порты (используя porticus) git: <a href="http://github.com/brotherbard/gitx/downloads">gitx</a> </p><p>если бы я все настроил по-новому, я бы сделал:</p><ol> <li> <p>установить <a href="http://www.panic.com/coda/">coda</a> </p> </li> <li> <p>установить <a href="http://porticus.alittledrop.com/download.html">porticus</a> (для этого потребуется установить порты, но на этой странице есть информация)</p> </li> <li> <p>после того, как вы установили porticus, откройте его, найдите "git-core" и установите его.</p> </li> <li> <p>скачать и установить <a href="http://github.com/brotherbard/gitx/downloads">gitx 7-5</a> </p> </li> <li> <p>существует хорошее руководство по настройке git-репо <a href="http://toolmantim.com/thoughts/setting\_up\_a\_new\_remote\_git\_repository">здесь</a> , но в его основе: 1. откройте терминал. 2. <code>cd</code> туда, где вы хотите разместить свой сайт. <code>$: mkdir mysite && cd mysite 3. $: git init</code> и это все! если вы добавляете файлы в эту папку, переходите к следующему шагу</p> </li> <li> <p>как только вы настроили git-репозиторий локально (см. выше), тогда, если вы откроете этот каталог в gitx, вы сможете фиксировать что-то и т.д.</p> </li> </ol><p>настроить все это на сервере может быть немного сложно, у меня есть mediatemple и учетная запись dreamhost, которые оба имеют git из коробки. ссылка в 5. рассказывает, как добавить удаленное репо, вам не нужно делать это, пока вы не захотите привести свой живой сайт в уравнение. я бы порекомендовал, чтобы сначала все работало локально (в отличие от svn, git не требует удаленного хранилища, поэтому вы можете пока что загружать все на своей машине)</p>

<p>я использую svn для контроля версий с<em> все </em>я делаю в разработке wordpress. я действительно начал этот путь, потому что мне был нужен svn для разработки плагинов ... как только я начал там, это было естественное расширение, чтобы продолжать использовать svn для тем и пользовательских скриптов на клиентских сайтах.</p><h3>плагины</h3><p>поскольку плагины уже размещены на сервере wordpress, я просто извлекаю плагин непосредственно в каталог <code>/wp-content/plugins/</code> моей локальной установки wordpress (я запускаю wamp на своем компьютере для разработки). затем я делаю изменения в своей локальной копии и, когда она будет готова к показу, фиксирую в хранилище. там все идет гладко, без выгрузки/загрузки и мгновенной проверки того, что мои изменения сработали.</p><h3>темы</h3><p>темы немного отличаются, особенно при создании для клиента. я создаю локальный репозиторий (у меня есть раздел <code>r</code> на моем жестком диске специально для этой цели) и извлекаю пустой репозиторий прямо в мой каталог <code>/wp-content/themes</code>. затем я делаю изменения по мере необходимости и развиваюсь до тех пор, пока он не будет готов, внося изменения по мере продвижения.</p><p>когда я готов опубликовать тему на производственном сервере клиента, я экспортирую репозиторий, заархивирую его и использую встроенные функции темы >> добавить новые в wordpress. это работает и с пользовательскими плагинами (которые не размещаются на wordpress).</p><h3>инструменты</h3><p>как я уже сказал, я использую wamp на своем локальном компьютере для запуска установочной установки wordpress. он отлично работает на моем компьютере и позволяет мне запускать столько экземпляров wordpress, сколько мне нужно для конкретного проекта.</p><p>для svn я использую <a href="http://tortoisesvn.tigris.org/">черепаха svn</a> . он бесплатный, удивительно простой в использовании и интегрируется со структурой файлов и команд windows. обновление, фиксация и экспорт - все это просто щелчок правой кнопкой мыши, выбор командных операций. использование "экспорт" позволяет отправлять всю папку (без надоедливых папок <code>.svn</code>) напрямую в любое место по вашему выбору - я часто экспортирую на рабочий стол. архивирование папки также выполняется правой кнопкой мыши, а wordpress выполняет загрузку.</p><p>передача файлов вручную может быть хлопотной, особенно если вы продолжаете изменять один файл, но не все. если вместо этого вы используете ftp по всему каталогу с выбранным "перезаписать все", гораздо проще заменить старые файлы (и вам не нужно отслеживать, какие изменения были, а какие нет). это похоже на старую 5-минутную установку wordpress - просто замените все на новую версию.</p>

<p>лично я считаю, что это забавное упражнение - установить svn/git и управлять им, но если вы можете заработать $ 15 в месяц, beanstalk стоит каждого пенни. они управляют всем сервером за вас. <a href="http://beanstalkapp.com/">http://beanstalkapp.com/</a> инструменты развертывания ftp потрясающие. мой автоматически развертывает версию на моем промежуточном сервере, когда я, например, фиксирую</p><p>другой способ получить личные версии файлов - использовать выпадающий список. каждый раз, когда вы сохраняете файл в свой дропбокс, он отслеживает версию, и вы можете позже вернуться к любой предыдущей версии. вы и другой разработчик или группа можете открыть общий доступ к папке дропбокс. конечно, это не позволяет выполнять транки, слияния и т.д., но позволяет распределенной команде очень легко работать на одном веб-сайте. вы просто не можете реально работать над одними и теми же файлами одновременно.</p><p>мы сохраняем нашу рабочую копию svn в dropbox, затем я фиксирую файлы, когда наступит время записи. мои дизайнеры не будут фиксировать файлы или иметь дело с svn, так что это компромисс.</p><p>я предпочитаю svn, потому что мне не нужны все транкинги, для которых git так хорош, и для svn доступны лучшие инструменты с графическим интерфейсом.</p>

<p>мне нравится <a href="http://www.aptana.com/">aptana</a> много, в него встроена subversion, и вы можете легко подключиться к вашему серверу с помощью ftp/sftp и push-файлов, еще одна замечательная особенность, которую он имеет, заключается в том, что если вы создаете новый проект php и включаете "вся" папка wordpress (с wp-admin, wp-includes) вы получаете завершение кода в файлах вашей темы.</p><p>в моей настройке репо локально.</p>

<p>вы спрашиваете "но я ищу конкретные примеры установок/рабочих процессов, которые люди используют для хранения истории версий отредактированных файлов на сайте wordpress", но вы также упоминаете продукты :)</p><p>вы получите выше, как ответ на список инструментов и некоторые лучшие практики, но я сосредоточусь здесь на рабочих процессах: они не беспокойные, специфичные:</p><p>но для общих примеров/настроек/рабочих процессов:</p><p>для начала: есть шаблоны cm, которые не зависят от инструментов. google on cm patterns, много книг, даже вики-сообщества, например <a href="http://www.cmcrossroads.com/forums">http://www.cmcrossroads.com/forums</a> .</p><p>существуют также руководства по настройке действующей стратегии потоковой передачи (стратегии потоковой передачи google) и т.д.</p><p>я не думаю, что есть что-то особенное в развертывании wordpress по сравнению с cm management, включая распределенную параллельную разработку на крупных фабриках siebel, sap, informatica, java и т.д. это действительно почти по умолчанию.</p><p>мне кажется, что не хватает того, что никто еще не написал cmplan для разработки на wordpress (пока) (ieee). однажды кто-то сделал это (независимо от инструмента). требования могут быть заполнены, я думаю, любым инструментом.</p><p>я думаю, что причина того, что план не был написан, состоит в том, что почти все реализации wordpress по-прежнему выполняются одним человеком с простой настройкой разработки-производства, поэтому многим разработчикам/дизайнерам на этапе сборки не приходится развертывать разные версии, работающие в тестовая среда, например.</p><p>план cmp начинается с определения всех элементов конфигурации, другими словами: составьте список всех типов элементов конфигурации, присутствующих в реализации wordpress, включая приложения, плагины, базу данных, документацию, справку, содержимое, файлы конфигурации, заметки о выпуске (!) и т. д. ..). это хорошее начало. затем решите, какие из них вы хотите взять под cm.</p><p>затем решите, что вызывает изменения в этих ci, например. вызов клиента для исправления ошибки или необходимого обновления. если все сделано правильно, это приводит к ситуации, когда вы чувствуете, что все под контролем.</p><p>решения, такие как слияние с производства на разработку и способ обработки этого, являются частью этой главы (2 основных шаблона здесь) (хотя, конечно, вы должны попытаться свести к минимуму эти исправления).</p><p>только позже ищите инструмент для выполнения cm с одной стороны (который включает управление версиями в качестве одного из инструментов) и инструменты управления изменениями с другой стороны (что держит вас в здравом уме).</p><p>я думаю, что это лучший рабочий процесс для начала, так как, насколько я гуглил, еще никто не сделал. я думаю, что как только первый человек написал план wordpress cm (согласно ieee), каждый второй человек в мире wordpress может скопировать этот план, внести коррективы и внедрить шаблоны в свои инструменты.</p><p>разве это не слишком много работы/не слишком тяжело: зависит от того, есть ли у вас компания или нет: это может сэкономить вам время на то, чтобы иметь хороший план cm.</p>

<p>я на общем хосте, поэтому я не могу установить svn или что-то подобное. я использую mercurial для контроля версий на моей домашней машине. я использую ftp-синхронизацию beyond compare для синхронизации локальных и удаленных папок.</p>

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