На большинстве серверов история изменений хранится только в головах команды. Кто-то поменял цены в магазине, кто-то поправил права, кто-то обновил конфиг плагина - и через неделю никто не помнит, что было до этого и почему всё сломалось. Git решает эту проблему. Это система контроля версий, которой пользуются программисты, но она не менее полезна для администраторов. Разберёмся, как использовать Git в Minecraft-проекте.
Что такое Git простыми словами
Git - это журнал изменений для файлов. Каждый раз, когда вы что-то меняете и сохраняете «снимок», Git запоминает, что именно поменялось, кто это сделал и зачем. В любой момент можно посмотреть историю, сравнить версии и вернуть файл к любому прошлому состоянию.
Для сервера это означает, что каждое изменение конфигов, прав и настроек записано с пояснением. Если после обновления что-то сломалось, вы видите, что именно поменялось, и можете откатить это за минуту.
Что класть в репозиторий
В репозиторий стоит класть текстовые файлы, которые описывают настройку сервера: конфиги плагинов, настройки ядра, файлы прав, если они хранятся в файлах, скрипты запуска и бэкапов. И, конечно, исходный код своих плагинов, если вы их пишете.
Не стоит класть туда миры, логи, базы данных и большие бинарные файлы. Миры весят гигабайты и постоянно меняются - для них есть бэкапы. Логи и базы данных - не настройки, а данные. Jar-файлы плагинов тоже лучше не хранить в Git, а записать в отдельный файл список плагинов с версиями.
Секреты не должны попасть в репозиторий
Самая опасная ошибка - закоммитить пароли. В конфигах плагинов часто лежат пароли от базы данных, токены ботов, ключи API. Если такой репозиторий окажется публичным или им поделятся с подрядчиком, все эти доступы утекут.
Решение - вынести секреты в отдельные файлы, которые исключены из репозитория через .gitignore, а в репозиторий положить шаблоны с пустыми значениями. Если пароль всё-таки попал в историю, недостаточно удалить его из файла: он остаётся в прошлых версиях. Его нужно сразу сменить.
Как работать на практике
Простейший процесс выглядит так. Перед изменением конфигов вы проверяете, что всё прошлое сохранено. Вносите изменения, проверяете их на тестовом сервере и сохраняете снимок с понятным описанием: «поднял цены на алмазы в магазине на 20%», «выдал модераторам право на тайм-аут». Затем переносите изменения на основной сервер.
Описание - самая важная часть. «Изменения» или «фикс» через месяц ничего не скажут. «Отключил автоферму мобов в мире ресурсов из-за лагов» - скажет всё.
Удалённый репозиторий и команда
Репозиторий удобно хранить на GitHub, GitLab или другом сервисе - обязательно приватным. Тогда у каждого члена команды есть доступ к истории, а у вас - дополнительная копия всех настроек.
Если над сервером работают несколько человек, Git показывает, кто что менял, и помогает не затирать чужие изменения. Можно даже договориться, что любые изменения важных конфигов сначала смотрит второй человек - так ловятся опечатки и неудачные решения до того, как их увидят игроки.
Откат за минуту
Главная польза проявляется в момент аварии. После обновления конфига экономики игроки жалуются, что цены сломались. Вы открываете историю, видите изменение, возвращаете файл к прошлой версии, перезагружаете плагин - и всё работает. Без Git пришлось бы вспоминать, какие значения были раньше, или искать их в бэкапе.
Git для своих плагинов
Если вы пишете плагины, Git - обязательный инструмент. Он хранит историю кода, позволяет пробовать новые функции в отдельных ветках, не ломая рабочую версию, и помогает найти, в какой момент появилась ошибка. А при работе с подрядчиками репозиторий - лучший способ получать результат: вы видите каждое изменение, а не только итоговый jar.
Пример
На сервере после правок права модераторов внезапно перестали работать, и два дня никто не мог понять почему. Администратор завёл репозиторий для конфигов, и следующая похожая проблема решилась за пять минут: история показала, что один из помощников случайно удалил строку наследования группы. Файл вернули к прошлой версии, а команда договорилась сохранять каждое изменение с описанием.
С чего начать, если вы никогда не пользовались Git
Не нужно сразу осваивать командную строку. Есть удобные программы с графическим интерфейсом, например GitHub Desktop: там изменения видны списком, а сохранение снимка - это одна кнопка и поле для описания. Начните с одной папки конфигов основного сервера: добавьте её в репозиторий, сделайте первый снимок «исходное состояние» и дальше сохраняйте каждое изменение.
Через пару недель вы заметите, что перестали бояться правок: любое изменение можно увидеть и отменить. А когда в команде появится новый администратор, история репозитория расскажет ему о сервере больше, чем любая документация.
Ещё один совет: делайте снимки маленькими. Одно изменение - один снимок с понятным описанием. Если сохранить сразу двадцать правок в разных плагинах, потом будет сложно откатить только одну из них.
Наш взгляд
Git нужен не только программистам. Для администратора он превращает хаотичные правки конфигов в понятную историю, где видно, кто, что и зачем менял, и где любое неудачное изменение откатывается за минуту. Главное - не класть в репозиторий секреты и писать понятные описания изменений. Начать можно с одной папки конфигов уже сегодня - через месяц вы не поймёте, как обходились без этого. А первая же быстрая починка после неудачной правки окупит всё время на освоение.
Храните ли вы конфиги сервера в Git или всё в голове команды?
