¶ Ссылки
¶ Актуальные гайды
Visual Studio Code Установка и настройка редактора кода
Unix & Docker Настройка рабочего окружения
Пайплайн работы с задачами Жизненный цикл разработки фичи
¶ Устаревшие гайды
Код-стайл для Lua Правила написания и работы с кодомУстановка под Windows
Установка под Linux
Конфигурация игрового сервера
Установка MySQL
¶ Подготовка
- Установи и настрой VS Code по инструкции
- Настрой свое рабочее окружение по инструкции
- Установи проект, над которым ты будешь работать по инструкции в его файле README
¶ Разработка
¶ Именование
¶ Сообщения коммитов
Сообщения коммитов публикуются на наших информационных ресурсах вроде Discord-сервера, поэтому мы стараемся более-менее дружелюбно описывать, что изменили в коде. Конечно же, в первую очередь мы это пишем для коллег, но по возможности круто также обозначить, что это может значить для игроков
Для упрощения поиска и классификации изменений мы используем систему GitMoji. Это очень просто: в начале сообщения ставим эмодзи, его можно скопировать либо с сайта, либо воспользоваться расширением, про которое написано в гайде по VS Code. Есть небольшое дополнение: чтобы сделать сообщение кинфиденциальным и скрыть содержание в публичных каналах, ставь в самое начало эмодзи шпиона: 🕵️, другие эмодзи это не отменяет, можно их совмещать
¶ Создание ветки
Все задачи, которые как-то могут повлиять на работоспособность сервера, надо выполнять в отдельной ветке, будь то исправление ошибки или же целая новая фича. Исключение здесь составляют, пожалуй, простые согласованные заранее изменения конфигов. Если единственное изменение – это пара констант, то можно пропустить создание ветки и пушнуть напрямую в dev, а в других случаях:
- Перейди в ветку репозитория, откуда будет создаваться новая, чаще всего это
dev. Никогда не используйmaster- все коммиты должны так или иначе проходить черезdev - Создай ветку для своих изменений из ветки, в которую ты перешел в предыдущем шаге. Предположим, ты хочешь создать ветку с названием, скопированным из трекера задач (Linear), например
feature/dbg-123-новая-фича, находясь сейчас в ветке с названиемdev:
git checkout dev
git pull
git checkout -b feature/dbg-123-новая-фича
- Работаешь в этой ветке: пишешь код, коммитишь изменения и пушишь в репозиторий
¶ Отправка запроса на слияние (merge request)
-
Когда работа закончена, создай новый запрос на слияние в соответствующей вкладке репозитория, в котором ты работаешь:
-
В качестве «Source branch» выбери ветку, в которой выполнена задача, а в «Target branch» ветку, в которую надо влить изменения, чаще всего это та, из которой запускалась новая на шаге 2
-
Можно указать название фичи и составить описание к ней, бот коммитов отобразит это в дискорде. Добавь префикс "Draft: " в названии запроса, чтобы показать, что ты его ещё не доделал, и его пока не нужно принимать. Если MR относится к задаче, можно также отразить это с ее ID в названии
-
Напиши в канал #code в офисе с пингом тех разработчиков, от кого требуется одобрение твоего MR
¶ Доработка
- Если нужно что-то доделать, а твой запрос еще не был одобрен, просто пушни свои коммиты в эту же ветку. В противном случае создавай новую ветку или выполни изменения уже в «Source branch» (см. создание ветки)
- Если задача затягивается, нужно время от времени обновлять свою ветку, делая
git mergeиз целевой ветки, чтобы избежать конфликтов