amit
  • 0
Учитель

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

  • 0
Закрыто. Этот вопрос
не по теме. В настоящее время ответы не принимаются.

Share
  1. Просто любопытно, Майк, почему заголовок редактируется? На мой взгляд, названия вопросов должны следовать правилам правильной грамматики. Может быть, это хорошая дискуссия для мета…

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

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

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

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

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

    1. Установить коду

    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 не требует удаленного репозитория, поэтому пока вы можете делать все на своем компьютере).

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

    Плагины

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

    Темы

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

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

    Инструменты

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

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

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

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

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

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

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

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

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

    • 0
  6. Вы спрашиваете «но я ищу конкретные примеры настроек/рабочих процессов, которые люди используют для хранения истории версий отредактированных файлов на сайте WordPress», но вы также упоминаете продукты 🙂

    Выше вы получите ответ со списком инструментов и некоторыми рекомендациями, но я сосредоточусь здесь на рабочих процессах: ОНИ НЕ СПЕЦИАЛЬНЫ ДЛЯ WORDPRESS:

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

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

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

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

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

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

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

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

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

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

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

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

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

    • 0
  8. я использую гит. это просто. вам нужно только понять простые команды, такие как клонировать, комитировать, нажать, вытащить, и вы готовы к работе. это основное.

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

    • 0

Оставить ответ

You must login to add an answer.