GIT или FTP: оптимизируем работу над веб-проектом (и не только)

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

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

Кстати, все сказанное здесь применимо не только к веб-разработке, но и к любой работе с локальными и удаленными файлами – медиа, документации и проч.

Сегодня существует два основных способа работы с файлами:

1. Посредством FTP-клиента через одноименный протокол
2. С помощью системы управления версиями

Рассмотрим оба варианта подробно.

Передача данных по FTP

File Transfer Protocol (FTP) был создан и принят более 50 лет назад – даже на 20 лет раньше, чем HTTP. Как водится, начиналось все с малого и простого: пользователи работали через командную строку, а передаваемые объемы были довольно скромными. По мере того, как развивались технические возможности, совершенствовался и протокол FTP. Благодаря этому он используется и сегодня.

Архитектура “клиент-сервер”, используемая протоколом, позволяет с помощью все той же командной строки или вполне себе удобного GUI приложения связаться с удаленным хостом, авторизоваться (или получить анонимный доступ) и выполнить операции по загрузке (upload) или скачиванию (download) необходимых файлов.

Как уже говорилось выше, протокол FTP развивается и совершенствуется. Использование SSH позволяет шифровать не только ваш логин и пароль, но и передаваемые данные. Тему безопасности продолжила разработка протоколов FTPS и SFTP.

Достоинства и недостатки FTP применительно к веб-разработке

Я уверен, что каждый веб-разработчик начинал с использования FTP-клиента в качестве основного (и единственного) средства выполнения файловых операций на удаленном сервере. Конечно, большую роль играет выработанный вами workflow. Например, кто-то привык к работе с проектом в собственной среде разработки на локальном хосте, после чего производится его выгрузка на удаленный сервер. Возможно, некоторые разработчики работают с файлами “на лету”, открывая и сохраняя их через FTP-клиент. Конечно, все это просто и доступно, если бы не одно (а скорее несколько) “но”:

1. Если вы изменили файлы локально из разных папок, необходимо или загрузить их вручную поодиночке (а это очень трудоемко) или скопировать сразу всю корневую папку с сайтом (со всеми вытекающими из этого последствиями).
2. Отследить изменения, сделанные по FTP, практически невозможно: не будете же вы открывать блокнот и расписывать в нем все свои правки пофайлово.
3. При совместной работе (или работе с нескольких компьютеров) вероятность конфликтов крайне высока.
4. Откатить изменения без использования бэкапа практически невозможно. Поэтому перед началом любых более-менее важных правок вам придется делать резервную копию всей сборки, находящейся на удаленном сервере.

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

Использование системы управления версиями при разработке сайта

Система управления версиями (VCS, version control system) представляет собой приложение для оптимизации работы (в том числе совместной) с изменяемыми данными. Подобных систем – платных и бесплатных – существует немало. Из наиболее известных у веб-разработчиков можно назвать Subversion (SVN) и наиболее популярный сегодня Git. На его примере рассмотрим принцип работы и преимущества систем управления версиями.

Принцип работы Git

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

В общих чертах схема использования VCS Git следующая:

1. Командой init создаем локальный репозиторий, куда помещаем исходные файлы будущего проекта.
2. Создаем и настраиваем удаленный репозиторий – на вашем хостинге или на сервисе типа GitHub.
3. Загружаем файлы проекта: первоначально это будет вся сборка, в дальнейшем будут автоматически выгружаться только измененные файлы.
4. Пакет изменений формируется командами add и commit и называется коммитом (commit). Система фиксирует дату и время каждого коммита, его автора и все сделанные изменения. Каждый коммит имеет свой уникальный hash-идентификатор. Их список можно получить командой reflog.
5. К работе над проектом можно подключать других разработчиков. Им понадобится доступ к репозиторию. Получив доступ, они смогут скачать репозиторий (или его часть) на локальную машину командой clone и работать над ним параллельно с вами и другими членами команды.
6. Система не допустит отправки коммита командой push в удаленный репозиторий, который уже был изменен другим пользователем. Вам будет предложено вначале выполнить pull чтобы скачать изменения и применить их в вашем локальном репозитории и учетом ваших собственных изменений. Только после этого вы сможете выгрузить свой коммит.
7. Перед началом работы или в ее процессе вы можете использовать команды fetch и pull для просмотра и получения изменений в удаленном репозитории.
8. Командой revert можно точечно “откатить” коммит – если нет конфликта с последующими внесенными в данный фрагмент (фрагменты) кода изменениями. Отмененный код будет сохранен в истории изменений репозитория, и вы сможете получить доступ к нему в любое время (например, если все-таки решите вернуть его).
9. Команда reset произведет откат всех коммитов, начиная с указанного.
10. С помощью ветвления и слияния можно разделять задачи по написанию нового кода, тестировать его и безопасно внедрять в действующий проект.

Возможности 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-клиент в нем можно настроить через плагин.

Ранее речь шла о базовом функционале блога и примерах его реализации.