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

Напоминаю, наша задача: после каждой правки делать «коммит» и иметь возможность вернутся к любому коммиту в прошлом. Ну и, конечно, иметь наглядную историю доработок на проекте.

На этом этапе мы будем считать, что вы уже подключились к серверу с помощью SSH и смотрите в окно терминала. Первым делом перейдите в папку с проектом, используя команду cd (сменить директорию). Как только вы добрались до нужного пути, выполняем:

Шаг 0. Нужно рассказать Git кто мы такие. Выполняем следующие команды:

git config --global user.name "Name Surname"
git config --global user.email "example@gmail.com"

Теперь при коммите будет отображаться наше имя.

Шаг 1. Инициализируем репозиторий.

git init

Шаг 2. Рассказываем Git, что у нас есть репозиторий на GitLab (там, конечно, нужно зарегистрироваться и создать репозиторий. Это просто, подробного описания делать не буду). Это как раз то самое удобное место, откуда мы будем брать всю интересную нам информацию. Конечно, можно брать ее из командной строки, а можно немного упростить себе жизнь. Необходимая команда будет выдана самим GitLab после создания пустого проекта:

git remote add origin git@gitlab.com:account/project_name

Шаг 3. Самый важный шаг для существующих проектов, особенно интернет-магазинов. Нам нужно выбрать файлы и директории, которые мы будем игнорировать. Вы же не хотите следить за изменениями внутри jpg-изображений ваших товаров?

Игнорируемые файлы настраиваются в папке .git/info/exclude

Обратите внимание, что папки, которые начинаются с точки, по умолчанию скрыты. Поэтому установите флажок «Показывать скрытые и системные файлы» в вашем SFTP-клиенте (я пользуюсь Transmit). Чтобы игнорировать картинки, просто укажите в этом файле с новой строки «*.jpg». Также рекомендую игнорировать архивы, логи, pdf и все остальное, что не имеет дела к программированию.

Шаг 4. Добавляем в проект все файлы, кроме игнорируемых:

git add .

Точка здесь означает «все файлы». Если у вас большая современная CMS, это займет некоторое время. Но не очень большое, если ожидание затянулось, можно прервать операцию командой CTRL+C и еще раз проверить, все ли файлы вы игнорируете на шаге 3.

Шаг 5. Делаем первый коммит:

git commit

Нас попросят ввести комментарий к коммиту, а затем дело сделано. Теперь нужно только передать всю нашу работу в GitLab:

git push -u origin master

Собственно, на этом все. Заходим на GitLab и видим, что файлы проекта успешно загрузились:

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

Чтобы при очередной правке не поломать сайт, были придуманы специальные системы, которые следят за изменениями файлов и позволяют вернуть время вспять. Попутно также решается проблема работы двух и более разработчиков над одним проектом — они могут работать параллельно и не мешать друг другу, а когда настанет время внедрения, их работа будет автоматически (если повезет) или с помощью главного разработчика объединена.

Я всегда пользовался Mercurial (HG) для контроля версий. Она просто ставится, у нее легкие запоминающиеся команды и разобраться в ней очень просто. К ней также есть много приложений-визуализаторов, которые показывают изменения, ветки, коммиты и прочие радости не в виде командной строки, а в пользовательском графическом интерфейсе. И в целом технология меня устраивает, но ведь все почему-то вокруг меня уходят из Mercurial в его конкурента — Git. Сегодня я решил, что не должно это пройти мимо меня, и начал изучать что к чему. По факту, конечно, это такая система контроля версий, просто к ней прикручено гораздо больше интересных сервисов, а для визуализации процесса разработки уже и программа-то не нужна — все делают специализированные онлайн-сервисы, например GitLab. Схема работы строится следующим образом: на сервере инициируется репозиторий, потом он клонируется на gitlab и эта связь постоянна. Разработчики не получают доступ к серверу! Они могут скопировать сайт с gitlab к себе на сервер, провести доработку, оттестировать ее и отправить на gitlab обратно. И оттуда уже доработка пойдет в бой, на главный сервер. На мой взгляд, это очень удобно и практично с точки зрения безопасности бизнеса — сервер всегда в руках бизнеса, любую доработку можно откатить, если все пошло совсем не так. Главное не забывать делать резервные копии баз данных.

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

Невероятно правильный подход. Получается, что порог входа в системы контроля версий значительно снижается. Все-таки нужно признать, что Mercurial изучить чуточку сложнее, во многом из-за страшного вида документации на десятки страниц, где для старта нужно всего 2-3 команды, как на скриншоте выше.