Руководство по работе с Git

Версия от 08:49, 27 мая 2026; M 9SCO (обсуждение | вклад) (Новая страница: «{{DISPLAYTITLE:Руководство по созданию Pull Request}} Категория:Разработка Категория:Гайды для контрибьюторов = Руководство по созданию Pull Request = Данное руководство описывает процесс создания Pull Request (PR) в репозиторий '''Orion Station 14'''. Следование этим правилам уск...»)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)


Руководство по созданию Pull Request

Данное руководство описывает процесс создания Pull Request (PR) в репозиторий Orion Station 14. Следование этим правилам ускоряет ревью и снижает вероятность отклонения вашего вклада.

Подготовка

Форк и клонирование

  1. Перейдите на страницу репозитория и нажмите Fork.
  2. Склонируйте свой форк:
git clone https://github.com/ВАШ_ЛОГИН/Orion-Station-14.git
cd Orion-Station-14
  1. Добавьте основной репозиторий как upstream:
git remote add upstream https://github.com/M9SCO/Orion-Station-14.git
  1. Запустите скрипт инициализации подмодулей:
python RUN_THIS.py

Создание ветки

// ВажноALERT
!
Никогда не работайте напрямую в ветке master. Всегда создавайте отдельную ветку под каждый PR.
git checkout master
git pull upstream master
git checkout -b тип/краткое-описание

Примеры имён веток:

  • feature/mora-12-gravity-bike — новая фича
  • fix/emote-restore — исправление бага
  • locale/update-anonymous — изменения локализации
  • sprites/new-clothing — добавление спрайтов
  • tweak/adminwho-visibility — небольшая правка

Правила оформления PR

Заголовок

Заголовок PR должен быть коротким и информативным. Используйте префикс, описывающий тип изменений:

Префикс Назначение Пример
feature: Новая функциональность feature: добавить гравибайк Mora-12
fix: Исправление бага fix: восстановить общие эмоции
tweak: Небольшая правка/балансировка tweak: изменить урон бейсбольной биты
locale: Изменения локализации locale: обновить анонимные имена
sprites: Добавление/изменение спрайтов sprites: добавить спрайты гравибайка
refactor: Рефакторинг кода refactor: вынести логику крафта в отдельную систему
// ВниманиеWARN
⚠
Не используйте общие заголовки вроде «Update файл.txt» или «Global update». Заголовок должен описывать суть изменений.

Описание (Body)

Каждый PR обязан содержать описание. Используйте следующий шаблон: 

## Что изменено
Краткое описание ваших изменений (2–3 предложения).

## Зачем
Причина или мотивация для данного изменения.

## Скриншоты / Медиа
<!-- Если PR затрагивает визуал (спрайты, UI) — приложите скриншоты или GIF -->

## Чеклист
- [ ] Я протестировал(а) изменения локально
- [ ] Код собирается без ошибок
- [ ] Нет конфликтов с веткой master
- [ ] Изменения затрагивают только то, что заявлено в PR

Типичные ошибки

1. Дублирование PR

// ВниманиеWARN
⚠
Не создавайте несколько PR с одним и тем же содержимым.

Если ваш PR требует доработки — обновите существующий, а не создавайте новый: 

# Внесите исправления в код, затем:
git add .
git commit -m "fix: учтены замечания из ревью"
git push origin ваша-ветка

Существующий PR обновится автоматически. Создание дубликатов (как PR #9, #10, #11) засоряет историю и усложняет ревью.

2. Работа в master

Работа напрямую в master создаёт конфликты при синхронизации с upstream и не позволяет параллельно вести несколько PR.

3. Слишком большой PR

Один PR = одна логическая единица изменений. Не смешивайте в одном PR:

  • Новую фичу + рефакторинг стороннего кода
  • Спрайты + изменения в C#-коде (если они не связаны)
  • Несколько независимых исправлений

4. Отсутствие тестирования

Перед созданием PR убедитесь, что:

  • Проект собирается (dotnet build)
  • Сервер запускается без ошибок
  • Ваши изменения работают в игре

Процесс ревью

После создания PR происходит следующее:

  1. Автоматические проверки — CI/CD прогоняет сборку и тесты.
  2. Сортировка — мейнтейнер выставляет лейблы.
  3. Code Review — один или несколько мейнтейнеров проверяют код.
  4. Запрос изменений — если есть замечания, от вас ждут коммиты в ту же ветку.
  5. Мерж — после одобрения PR вливается в master.
Что делать, если... Решение
CI упал Прочитайте логи сборки, исправьте ошибки, запушьте фикс в ветку PR
Появились конфликты Выполните git pull upstream master и разрешите конфликты локально
Долго нет ревью Напишите мейнтейнеру в Discord / оставьте комментарий в PR
PR отклонили Прочитайте причину, учтите замечания, создайте новый PR (если старый закрыт) или обновите текущий

Работа с конфликтами

Если ваш PR конфликтует с master: 

git checkout ваша-ветка
git fetch upstream
git merge upstream/master
# Разрешите конфликты в редакторе
git add .
git commit -m "merge: разрешение конфликтов с master"
git push origin ваша-ветка
// ВажноALERT
!
Используйте git merge, а не git rebase, если вы не уверены в том, что делаете. Rebase переписывает историю и может создать проблемы при командной работе.

Полезные ссылки

Краткая шпаргалка

# 1. Синхронизация с upstream
git checkout master && git pull upstream master

# 2. Создание ветки
git checkout -b feature/моя-фича

# 3. Работа и коммиты
git add файл1 файл2
git commit -m "feature: описание изменения"

# 4. Пуш и создание PR
git push origin feature/моя-фича
# → Перейдите на GitHub и нажмите "Create Pull Request"

# 5. Обновление PR после замечаний
git add .
git commit -m "fix: учтены замечания"
git push origin feature/моя-фича
Источник — https://wiki.siberiaserver.ru/index.php?title=Руководство_по_работе_с_Git&oldid=8411