GIT или FTP: оптимизируем работу над веб-проектом (и не только)
Популярные запросы: тема Omnis, плагин Pagelist, Cotonti 0.9.24.2, ЧПУ, Font Face
- 90 просмотров
- 9 сентября, 2024
- Обновлено: 12 октября, 2024
- admin
- Время чтения: 7 минут
- 4 (Подробно)
У каждого разработчика есть свой стиль или, если хотите, типовая методология работы с проектами. Как правило, на отработку уходит определенное время, после чего многие операции становятся на поток и превращаются не более чем в рутину.
Одной из таких рутинных операций является работа с файлами на локальном и удаленном сервере. Она предполагает создание или выгрузку файлов на удаленный сервер и дальнейшую работу с ними, а именно внесение изменений, добавление или удаление.
Кстати, все сказанное здесь применимо не только к веб-разработке, но и к любой работе с локальными и удаленными файлами – медиа, документации и проч.
Сегодня существует два основных способа работы с файлами:
- Посредством FTP-клиента через одноименный протокол
- С помощью системы управления версиями
Рассмотрим оба варианта подробно.
Передача данных по FTP
File Transfer Protocol (FTP) был создан и принят более 50 лет назад – даже на 20 лет раньше, чем HTTP. Как водится, начиналось все с малого и простого: пользователи работали через командную строку, а передаваемые объемы были довольно скромными. По мере того, как развивались технические возможности, совершенствовался и протокол FTP. Благодаря этому он используется и сегодня.
Архитектура “клиент-сервер”, используемая протоколом, позволяет с помощью все той же командной строки или вполне себе удобного GUI приложения связаться с удаленным хостом, авторизоваться (или получить анонимный доступ) и выполнить операции по загрузке (upload) или скачиванию (download) необходимых файлов.
Как уже говорилось выше, протокол FTP развивается и совершенствуется. Использование SSH позволяет шифровать не только ваш логин и пароль, но и передаваемые данные. Тему безопасности продолжила разработка протоколов FTPS и SFTP.
Достоинства и недостатки FTP применительно к веб-разработке
Я уверен, что каждый веб-разработчик начинал с использования FTP-клиента в качестве основного (и единственного) средства выполнения файловых операций на удаленном сервере. Конечно, большую роль играет выработанный вами workflow. Например, кто-то привык к работе с проектом в собственной среде разработки на локальном хосте, после чего производится его выгрузка на удаленный сервер. Возможно, некоторые разработчики работают с файлами “на лету”, открывая и сохраняя их через FTP-клиент. Конечно, все это просто и доступно, если бы не одно (а скорее несколько) “но”:
- Если вы изменили файлы локально из разных папок, необходимо или загрузить их вручную поодиночке (а это очень трудоемко) или скопировать сразу всю корневую папку с сайтом (со всеми вытекающими из этого последствиями).
- Отследить изменения, сделанные по FTP, практически невозможно: не будете же вы открывать блокнот и расписывать в нем все свои правки пофайлово.
- При совместной работе (или работе с нескольких компьютеров) вероятность конфликтов крайне высока.
- Откатить изменения без использования бэкапа практически невозможно. Поэтому перед началом любых более-менее важных правок вам придется делать резервную копию всей сборки, находящейся на удаленном сервере.
И это только то, что приходит в голову сразу. Работая в одиночку над небольшими проектами, возможно вы сумеете решить все проблемы. Но со временем большинство разработчиков приходят к использованию систем управления версиями, которые не только решают все эти проблемы, но и добавляют немало полезных возможностей.
Использование системы управления версиями при разработке сайта
Система управления версиями (VCS, version control system) представляет собой приложение для оптимизации работы (в том числе совместной) с изменяемыми данными. Подобных систем – платных и бесплатных – существует немало. Из наиболее известных у веб-разработчиков можно назвать Subversion (SVN) и наиболее популярный сегодня Git. На его примере рассмотрим принцип работы и преимущества систем управления версиями.
Принцип работы Git
Данная система управления версиями является распределенной. Это означает, что вы или ваши коллеги могут создавать у себя локальные копии основного удаленного репозитория. Это обеспечивает и надежность и более гибкий подход к работе. Другие системы, например SVN, являются централизованными. Это означает, что данные проекта всегда располагаются в едином хранилище.
В общих чертах схема использования VCS Git следующая:
- Командой
init
создаем локальный репозиторий, куда помещаем исходные файлы будущего проекта. - Создаем и настраиваем удаленный репозиторий – на вашем хостинге или на сервисе типа GitHub.
- Загружаем файлы проекта: первоначально это будет вся сборка, в дальнейшем будут автоматически выгружаться только измененные файлы.
- Пакет изменений формируется командами
add
иcommit
и называется коммитом (commit). Система фиксирует дату и время каждого коммита, его автора и все сделанные изменения. Каждый коммит имеет свой уникальный hash-идентификатор. Их список можно получить командойreflog
. - К работе над проектом можно подключать других разработчиков. Им понадобится доступ к репозиторию. Получив доступ, они смогут скачать репозиторий (или его часть) на локальную машину командой
clone
и работать над ним параллельно с вами и другими членами команды. - Система не допустит отправки коммита командой
push
в удаленный репозиторий, который уже был изменен другим пользователем. Вам будет предложено вначале выполнитьpull
чтобы скачать изменения и применить их в вашем локальном репозитории и учетом ваших собственных изменений. Только после этого вы сможете выгрузить свой коммит. - Перед началом работы или в ее процессе вы можете использовать команды
fetch
иpull
для просмотра и получения изменений в удаленном репозитории. - Командой
revert
можно точечно “откатить” коммит – если нет конфликта с последующими внесенными в данный фрагмент (фрагменты) кода изменениями. Отмененный код будет сохранен в истории изменений репозитория, и вы сможете получить доступ к нему в любое время (например, если все-таки решите вернуть его). - Команда
reset
произведет откат всех коммитов, начиная с указанного. - С помощью ветвления и слияния можно разделять задачи по написанию нового кода, тестировать его и безопасно внедрять в действующий проект.
Возможности Git можно перечислять еще очень долго. Однако базовых уже достаточно для того, чтобы оценить все перспективы его использования при разработке сайтов – даже для фрилансера, который большую часть времени работает самостоятельно.
Переходим на Git?
По большей части, да. Однако есть некоторые моменты, которые необходимо знать и применять. Прежде всего, это касается данных, которые необходимо (или желательно) исключить из репозитория.
Игнорирование файлов в Git
В любом проекте всегда найдутся файлы, которые по тем или иным причинам необходимо исключить из репозитория или проигнорировать. Их необходимо указать в файле .gitignore
и разместить его в корне проекта на локальной машине. Так вы проинструктируете Git не использовать эти данные при синхронизации (т. е. при получении и отправке коммитов).
Кстати, дистрибутив Cotonti имеет свой собственный дефолтный .gitignore, где указаны папки и служебные файлы, которые нет необходимости выгружать в репозиторий и на удаленный сервер.
Хороший пример – файл настроек config.php
Если на локальной машине вы работаете с проектом с использованием виртуального сервера, в нем будут прописаны соответствующие установки. При выгрузке его на удаленный сервер мы получим нерабочий проект. Именно поэтому config.php
по умолчанию мы не синхронизируем.
А как тогда вносить изменения в него (например, настройки кэширования)? Для этого вам понадобится старый-добрый FTP-клиент. Без него все-таки никак.
Еще один пример – файлы изображений и их миниатюры, загружаемые и создаваемые с помощью плагина Attach2. Их тоже лучше исключать из репозитория:
... /datas/attach/* !/datas/attach/index.html ...
А для работы под виртуальным сервером скачать папку с изображениями можно будет с помощью все того же FTP-клиента.
Конфликты и нарушение работы репозитория
Если ваш проект работает под системой управления версиями, позаботьтесь о том, чтобы не допускать использования FTP для изменения или удаления файлов из репозитория. Это нарушит его целостность и может привести к непредсказуемым последствиям. Исправить ситуацию, конечно, будет возможно “хирургическим вмешательством”, но головной боли это вам прибавит, особенно если проект реализуется командой.
Вместо заключения
Система управления версиями – в нашем случае Git – это musthave для любого разработчика, использующего системный подход в своей работе. Даже при минимальном использовании своего функционала Git позволит вам контролировать все изменения в проекте и, например, при возникновении ошибки, быстро возвращать на место рабочий код – независимо от того, когда и кем была допущена ошибка.
FTP-клиент не стоит исключать из вашего инструментария. С его помощью вы сможете работать с данными, которые по ряду причин необходимо исключить из репозитория. Речь здесь может идти о файлах настроек, серверном кэше, служебных и мультимедийных файлах из состава контента, загружаемого пользователями или администраторами.
Многие среды веб-разработки имеют встроенные средства для доступа к данному функционалу. Например, редактор Pulsar имеет встроенную поддержку Git, а FTP-клиент в нем можно настроить через плагин.
Ранее речь шла о базовом функционале блога и примерах его реализации.
А еще многие среды разработчика имеют встроенную поддержку Git. Например, тот же Atom / Pulsar.
Новый комментарий