Commit as of 2026-01-28 12:43:20 by Dis_Bro (Данил)
This commit is contained in:
parent
20a48ebca3
commit
c14c7bbdba
@ -43,7 +43,12 @@
|
||||
## Январь 2026
|
||||
- 26.01.2026 Dis_Bro
|
||||
- Добавил информацию о системе команд для новой платы, структурировал, расписал подробнее
|
||||
|
||||
- 28.01.2026 Dis_Bro
|
||||
- Обновил [[Стандарты]]:
|
||||
- Немного переписал [[Стандарты#C /Unity|C#/Unity]], добавил примеров
|
||||
- Добавил [[Стандарты#Git|Git]] с примерами и правилами для коммитов
|
||||
- Обновил [[Организационная структура]] под текущее положение дел
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -28,10 +28,16 @@
|
||||
Это не обязательный список, но максимально желательный
|
||||
|
||||
## Ссылки хранилища
|
||||
### Билды
|
||||
[Ссылка на билды фишки](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Conect4_builds)
|
||||
[Ссылка на билды промика](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Promo_builds)
|
||||
[Ссылка на билды морского боя](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Sea_battle_Cviat)
|
||||
### Проекты
|
||||
- Фишка:
|
||||
- [Ссылка на билды фишки](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Conect4_builds)
|
||||
- [Ссылка на исходники фишки](http://172.11.0.14:3000/Robotail/chip-game)
|
||||
- Данро:
|
||||
- [Ссылка на билды Данро](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Danro_builds)
|
||||
- [Ссылка на исходники Данро](http://172.11.0.14:3000/Robotail/Danro)
|
||||
- Морской бой:
|
||||
- [Ссылка на билды морского боя](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Sea_battle_Cviat)
|
||||
- [Ссылка на исходники морского боя](http://172.11.0.14:3000/Robotail/sea-battle)
|
||||
## Организация
|
||||
Сведения об организационной деятельностьи [[Организационная структура|в общем]] и в частности.
|
||||
```dataview
|
||||
|
||||
4
GreatGamedevVault/TEMP.md
Normal file
4
GreatGamedevVault/TEMP.md
Normal file
@ -0,0 +1,4 @@
|
||||
Файл для временного содержания
|
||||
|
||||
# Список установленных плагинов
|
||||
|
||||
@ -1,42 +1,53 @@
|
||||
# Ораганизация
|
||||
- Наличие тимлида
|
||||
- Распределение приоритетов
|
||||
- Отслеживание сроков
|
||||
- Код-ревью понеобходимости
|
||||
- Связь с начальством
|
||||
- Гит
|
||||
- Заливать и хранить на гите объемные ассеты долго и неудобно.
|
||||
- Пока разработка у каждого индивидуальная вопрос не слишком актуален
|
||||
- Папка на пандоре
|
||||
- Хороший переиспользуемый код. Обязательно README.
|
||||
- Билды по своим папкам
|
||||
- Закупленные или стыренные ассеты + README.
|
||||
- Запланированные на неделю мероприятия
|
||||
- Использование Obsidian для отслеживания выполненных задач (упрощает вспоминание "что делали" когда приходит время отчитываться)
|
||||
# Организация
|
||||
|
||||
## Текущие вопросы
|
||||
|
||||
> [!faq]- Наличие тимлида
|
||||
> - Распределение приоритетов
|
||||
> - Отслеживание сроков
|
||||
> - Код-ревью понеобходимости
|
||||
> - Связь с начальством
|
||||
|
||||
> [!answer]- Решение
|
||||
> - Пока оставить все как есть, делать все общими усилиями
|
||||
> - В перспективе выбрать одного из нас на роль, никаких Барбоскиных
|
||||
> - Улучшать оргструктуру
|
||||
|
||||
## Текущие решения
|
||||
|
||||
> [!done]- Гит
|
||||
> - Для объемных ассетов проекта использовать Git LFS под необходимые форматы
|
||||
> - Один проект - один репозиторий
|
||||
> - Писать содержание коммитов желательно в соответствии с [[Стандарты#Git]], для простого формирования отчетности
|
||||
> - Делать коммиты регулярно, желательно ежедневно или по таскам
|
||||
> - В дальнейшем прийти к более структурированным репозиториям
|
||||
> - Ссылки: [[README#Ссылки хранилища]]
|
||||
|
||||
> [!done]- Общая библиотека
|
||||
> - Хороший переиспользуемый код. Обязательно README в этом хранилище
|
||||
> - Закупленные или стыренные ассеты + README
|
||||
|
||||
> [!done]- Папка на пандоре
|
||||
> - Билды по своим папкам
|
||||
> - README для запуска проекта другими сотрудниками
|
||||
|
||||
> [!done]- Obsidian
|
||||
> - Запланированные на неделю мероприятия
|
||||
> - Использование Obsidian для отслеживания выполненных задач (упрощает вспоминание "что делали" когда приходит время отчитываться)
|
||||
|
||||
___
|
||||
# Стандарты и правила
|
||||
- Общий [[Стандарты]]
|
||||
- Общая [[Добавление файла в библиотеку|библиотека]] для складирования полезного переиспользуемого кода (менеджеры, паттерны, префабы, реюзабл механики)
|
||||
- Общие [[Стандарты]]
|
||||
- Общая [[Добавление файла в библиотеку|библиотека]] для складирования полезного переиспользуемого кода (менеджеры, паттерны, префабы, реюзабл механики)
|
||||
- Архитектура программы
|
||||
- Для индивидуальной разработки полагаемся на мнение чата, делаем как удобно
|
||||
- Коллективная разработка: Сначала проектируем на схемах, вместе мозгуем, потом следуем плану.
|
||||
|
||||
___
|
||||
# Недельный цикл работы
|
||||
# Недельный цикл работы
|
||||
|
||||
==Понедельник==
|
||||
- Планерка
|
||||
- Разбираем задачи с пятницы
|
||||
- Расставляем приоритеты
|
||||
==Пока под вопросом, в процессе разработки==
|
||||
|
||||
==Вторник-Четверг==
|
||||
- Фокус на разработку
|
||||
- При завершении задачи добавляем отработанную задачу в пул "на проверку"
|
||||
- Внеплановые собрания для помощи по необходимости
|
||||
|
||||
==Пятница==
|
||||
- Собираем билды
|
||||
- Проводим плейтесты
|
||||
- Собрать информацию о текущем состоянии проектов
|
||||
- Составляем обратную связь -> генерируем задачи на следующую неделю
|
||||
| День/дни недели | План работы |
|
||||
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Понедельник | Планерка<br> - Разбираем задачи с пятницы<br> - Расставляем приоритеты |
|
||||
| Вторник-Четверг | Фокус на разработку<br>При завершении задачи добавляем отработанную задачу в пул "на проверку"<br>Внеплановые собрания для помощи по необходимости |
|
||||
| Пятница | Собираем билды<br>Проводим плейтесты<br>Собрать информацию о текущем состоянии проектов<br>Составляем обратную связь -> генерируем задачи на следующую неделю |
|
||||
|
||||
@ -1,66 +1,244 @@
|
||||
# 1. Именование и стиль C-sharp
|
||||
# C#/Unity
|
||||
## 1. Именование и стиль C#
|
||||
|
||||
- **PascalCase**: классы, интерфейсы, методы, свойства, события.
|
||||
- **camelCase**: локальные переменные и параметры (spawnPoint, speed).
|
||||
- **\_camelCase**: приватные поля.
|
||||
- **UPPER_SNAKE_CASE**: const и static readonly.
|
||||
- **Namespaces**: Company.Product.Module → BobotailX.Gameplay.Combat.
|
||||
- **Один класс = один файл**. Публичные типы в отдельных файлах.
|
||||
- **var** — для очевидных типов, иначе явный тип.
|
||||
1. Именование:
|
||||
- **PascalCase**: классы, структуры, record’ы, enum’ы, методы, свойства, события.
|
||||
- **IInterfaceName**: интерфейсы (`IDamageable`, `IInputSource`).
|
||||
- **camelCase**: локальные переменные и параметры (`spawnPoint`, `moveSpeed`).
|
||||
- **_camelCase**: приватные поля (`_rigidbody`, `_cachedTransform`).
|
||||
- **UPPER_SNAKE_CASE**: только `const` (без `static readonly`).
|
||||
- **static readonly**: как обычное поле в **PascalCase** (`static readonly Vector3 DefaultOffset = ...`).
|
||||
- **Namespaces**: `Company.Product.Module` → `BobotailX.Gameplay.Combat`.
|
||||
- Суффиксы по смыслу: `*Service`, `*System`, `*Factory`, `*Controller`, `*Presenter`, `*View`, `*Settings`.
|
||||
2. Структура исходников:
|
||||
- **Один публичный тип = один файл** (файл называется как тип).
|
||||
- Допускаются несколько приватных типов в одном файле, если они служебные и не используются снаружи.
|
||||
- Предпочтительно использовать **file-scoped namespace** (если версия языка позволяет):
|
||||
```cs
|
||||
namespace BobotailX.Gameplay.Combat;
|
||||
|
||||
- Для автоформатирования периодически юзаем Ctrl+KD в VS
|
||||
public sealed class DamageSystem { }
|
||||
```
|
||||
3. Использование типов:
|
||||
- Явное указание типов **приветствуется всегда** и является предпочтительным по умолчанию.
|
||||
- **var** — допускается только при очевидном типе и при улучшении читаемости, без потери понимания (тип однозначен из правой части).
|
||||
- Для чисел и Unity API предпочтительнее явные типы (чтобы не путать `int/float`, `Vector2/Vector3`, `Transform/GameObject`).
|
||||
- Примеры:
|
||||
```cs
|
||||
// предпочтительно (ясный тип)
|
||||
float moveSpeed = 6.5f;
|
||||
|
||||
# 2. Unity-специфичные штуки
|
||||
Vector3 targetPosition = transform.position;
|
||||
|
||||
- Поля в инспекторе: \[SerializeField] private + public get (инкапсуляция лучше, чем public).
|
||||
- Компоненты кешируем в Awake/OnEnable (не дергать `GetComponent` каждый кадр).
|
||||
- Минимизируем работу в `Update()`; используем события, корутины.
|
||||
- В Input/Physics использовать `Time.[fixed]deltaTime`, не «магические» коэффициенты.
|
||||
- Не использовать `FindObjectOfType`/`Find` в рантайме
|
||||
- Использовать DI, ссылки через инспектор, фабрики, бутстрапы.
|
||||
- Конфиги — **ScriptableObject** (баланс, таблицы параметров).
|
||||
- Сцены:
|
||||
- **MainBootstrap** сцена с уникальным Bootstrap скриптом для загрузки менеджеров-синглтонов, существующих всю игру (GameManager, ContextManager, AudioManager)
|
||||
- Локальные Bootstrap'ы для сцен по необходимости
|
||||
// допустимо (тип очевиден и не снижает читаемость)
|
||||
var enemies = new List<GameObject>();
|
||||
var token = cancellationTokenSource.Token;
|
||||
```
|
||||
4. Современный C# (рекомендуется):
|
||||
- Включать **nullable reference types** (NRT) и избегать `null`-контрактов без необходимости.
|
||||
- Использовать **pattern matching**, `switch`-выражения, `readonly`/`init` при уместности.
|
||||
- Использовать `sealed` по умолчанию для классов без наследования (в Unity — осторожно, см. ниже).
|
||||
- Примеры:
|
||||
```cs
|
||||
#nullable enable
|
||||
public bool TryGetTarget(out Transform target)
|
||||
{
|
||||
target = _target;
|
||||
return target is not null;
|
||||
}
|
||||
|
||||
>Bootstrap'ы - реализация паттерна Entry Point. Удобно управлять порядком загрузки, чтобы не долбаться с настройкой Execution Order'а когда менеджеров >1 и зависимости усложняются
|
||||
public static int ClampToByte(int value) => value switch
|
||||
{
|
||||
< 0 => 0,
|
||||
> 255 => 255,
|
||||
_ => value
|
||||
};
|
||||
```
|
||||
5. Unity-ограничения для C#:
|
||||
- `MonoBehaviour`/`ScriptableObject` **не делать `new`**, создаются Unity.
|
||||
- `MonoBehaviour` обычно **не `sealed`**, если планируется наследование/моки; если наследование не нужно — `sealed` допустим.
|
||||
- Использовать `[SerializeField] private` вместо `public` полей.
|
||||
|
||||
# 3. Структура скрипта (порядок элементов)
|
||||
5. Форматирование:
|
||||
- Форматирование кода выполняется средствами IDE.
|
||||
- Для Visual Studio: **Format Document** (`Ctrl+K, Ctrl+D`) / **Format Selection** (`Ctrl+K, Ctrl+F`).
|
||||
- Для Rider: **Code Cleanup / Reformat Code** (настройки проекта фиксируются в `.editorconfig`).
|
||||
- Рекомендуется добавить `.editorconfig` и включить анализаторы (Roslyn/IDE).
|
||||
|
||||
## 2. Unity-специфичные штуки
|
||||
|
||||
1. Сериализация и Inspector:
|
||||
- Поля в инспекторе: `[SerializeField] private` + `public` свойства/геттеры (инкапсуляция лучше, чем `public`).
|
||||
- Для ссылок на компоненты/объекты сцены использовать **SerializeField** и префабы/инстансы, не поиск по имени.
|
||||
- Пример:
|
||||
```cs
|
||||
public sealed class PlayerMover : MonoBehaviour
|
||||
{
|
||||
[SerializeField] private Rigidbody _rigidbody = null!;
|
||||
[SerializeField] private float _speed = 6.5f;
|
||||
|
||||
public float Speed => _speed;
|
||||
|
||||
private void Awake()
|
||||
{
|
||||
// null! допускается, но лучше валидировать в OnValidate (см. ниже)
|
||||
}
|
||||
}
|
||||
```
|
||||
2. Валидация ссылок и настроек:
|
||||
- Для проверки сериализованных ссылок использовать `OnValidate()` (в редакторе) и/или рантайм-assert.
|
||||
- Пример:
|
||||
```cs
|
||||
private void OnValidate()
|
||||
{
|
||||
if (_rigidbody == null) TryGetComponent(out _rigidbody);
|
||||
}
|
||||
```
|
||||
3. Производительность:
|
||||
- Компоненты кешируются в `Awake`/`OnEnable` (не дергать `GetComponent` каждый кадр).
|
||||
- Работа в `Update()` минимизируется; предпочтение событиям, `Coroutine`, `Invoke`, таймерам.
|
||||
- Для частых операций — `FixedUpdate` (физика) или `LateUpdate` (камера), по назначению.
|
||||
- Пример (кэш + ранний выход):
|
||||
```cs
|
||||
private Transform _cachedTransform = null!;
|
||||
|
||||
private void Awake()
|
||||
{
|
||||
_cachedTransform = transform;
|
||||
}
|
||||
|
||||
private void Update()
|
||||
{
|
||||
if (!enabled) return;
|
||||
// минимальная логика, без тяжёлых аллокаций
|
||||
}
|
||||
```
|
||||
4. Время, ввод и физика:
|
||||
- Для движения/анимации использовать `Time.deltaTime`.
|
||||
- Для физики — `Time.fixedDeltaTime` и `FixedUpdate`.
|
||||
- Магические коэффициенты вместо времени кадра не допускаются.
|
||||
- Ввод рекомендуется через **Input System** (Unity package), а не старый `Input.*`.
|
||||
- Пример (Input System):
|
||||
```cs
|
||||
using UnityEngine.InputSystem;
|
||||
|
||||
public void OnMove(InputAction.CallbackContext ctx)
|
||||
{
|
||||
Vector2 input = ctx.ReadValue<Vector2>();
|
||||
_moveInput = input;
|
||||
}
|
||||
```
|
||||
5. Поиск объектов и зависимости:
|
||||
- Не использовать `FindObjectOfType`/`Find` в рантайме (особенно на мобильных/консолях).
|
||||
- Использовать DI (Zenject/VContainer), ссылки через инспектор, фабрики, bootstrap-инициализацию.
|
||||
- Исключение: редакторские утилиты и одноразовая диагностика в dev-сборках.
|
||||
6. Конфиги и данные:
|
||||
- Конфиги — **ScriptableObject** (баланс, таблицы параметров, ссылки на префабы).
|
||||
- Для адресуемого контента и крупных проектов — **Addressables**.
|
||||
- Пример `ScriptableObject`:
|
||||
```cs
|
||||
[CreateAssetMenu(menuName = "Gameplay/Player Settings")]
|
||||
public sealed class PlayerSettings : ScriptableObject
|
||||
{
|
||||
[field: SerializeField] public float MoveSpeed { get; private set; } = 6.5f;
|
||||
[field: SerializeField] public float JumpForce { get; private set; } = 7.0f;
|
||||
}
|
||||
```
|
||||
7. Ассембли и пакеты:
|
||||
- Рекомендуются **Assembly Definition Files (asmdef)** для разделения модулей, ускорения компиляции и чистых зависимостей.
|
||||
- Внешние зависимости — через `Packages/` (UPM), минимизировать «всё в Assets/ThirdParty».
|
||||
8. Сцены и Bootstrap[^1]:
|
||||
- **MainBootstrap** сцена с уникальным Bootstrap скриптом для загрузки сервисов/менеджеров на всю сессию (например: `GameManager`, `ContextManager`, `AudioManager`).
|
||||
- Локальные Bootstrap'ы[^1] для сцен по необходимости (UI, уровень, режим).
|
||||
- Рекомендуется грузить основную сцену **additive** и управлять жизненным циклом через SceneManager.
|
||||
- Пример (additive):
|
||||
```cs
|
||||
using UnityEngine.SceneManagement;
|
||||
|
||||
private IEnumerator Start()
|
||||
{
|
||||
yield return SceneManager.LoadSceneAsync("MainMenu", LoadSceneMode.Additive);
|
||||
}
|
||||
```
|
||||
|
||||
[^1]: Bootstrap'ы — реализация паттерна Entry Point. Удобно управлять порядком загрузки, чтобы не настраивать `Execution Order`, когда менеджеров больше одного и зависимости усложняются.
|
||||
|
||||
## 3. Структура скрипта (порядок элементов)
|
||||
|
||||
1. const/static readonly
|
||||
2. serialized поля
|
||||
2. serialized поля (`[SerializeField]`)
|
||||
3. приватные поля (неконфигурируемые)
|
||||
4. свойства/события
|
||||
5. **Unity Messages** (Awake, OnEnable, Start, Update, …)
|
||||
5. **Unity Messages** (Awake, OnEnable, OnDisable, Start, Update, FixedUpdate, LateUpdate, OnDestroy, …)
|
||||
6. публичные методы API
|
||||
7. приватные методы/вспомогательные
|
||||
8. вложенные типы
|
||||
|
||||
# 4. Организация папок проекта
|
||||
Assets/
|
||||
Scripts/
|
||||
Art/
|
||||
Models/
|
||||
Textures/
|
||||
Materials/
|
||||
Sprites/
|
||||
Animations/
|
||||
object1/
|
||||
animator
|
||||
clips
|
||||
object2/
|
||||
...
|
||||
Audio/
|
||||
Music/
|
||||
SFX/
|
||||
Prefabs/
|
||||
Scenes/
|
||||
UI/
|
||||
ThirdParty/
|
||||
Все что накачали/
|
||||
Пример минимального шаблона:
|
||||
```cs
|
||||
public sealed class Example : MonoBehaviour
|
||||
{
|
||||
private const int MaxCount = 10;
|
||||
|
||||
# 5. Аннотации инспектора
|
||||
Да, лишний прописывать их тратит время, но инспектор становитсяя красивым, удобным и читаемым.
|
||||
[SerializeField] private float _speed = 6.5f;
|
||||
|
||||
private int _count;
|
||||
|
||||
public float Speed => _speed;
|
||||
|
||||
private void Awake()
|
||||
{
|
||||
_count = 0;
|
||||
}
|
||||
|
||||
public void ResetCount()
|
||||
{
|
||||
_count = 0;
|
||||
}
|
||||
|
||||
private void Tick()
|
||||
{
|
||||
_count++;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 4. Организация папок проекта
|
||||
|
||||
```shell
|
||||
Assets/
|
||||
Scripts/
|
||||
Runtime/
|
||||
Editor/
|
||||
Tests/
|
||||
Art/
|
||||
Models/
|
||||
Textures/
|
||||
Materials/
|
||||
Sprites/
|
||||
Animations/
|
||||
object1/
|
||||
animator
|
||||
clips
|
||||
object2/
|
||||
...
|
||||
Audio/
|
||||
Music/
|
||||
SFX/
|
||||
Prefabs/
|
||||
Scenes/
|
||||
UI/
|
||||
ThirdParty/
|
||||
Все что накачали/
|
||||
Settings/
|
||||
ScriptableObjects/
|
||||
Resources/ (использовать по необходимости)
|
||||
Addressables/ (если используется Addressables)
|
||||
```
|
||||
|
||||
## 5. Аннотации инспектора
|
||||
|
||||
Да, лишний раз прописывать их тратит время, но инспектор становится красивым, удобным и читаемым.
|
||||
- Header
|
||||
- Tooltip
|
||||
- Range
|
||||
@ -68,14 +246,128 @@ Assets/
|
||||
- Max
|
||||
- Delayed
|
||||
- RequireComponent
|
||||
- ContextMenu (для отладочных кнопок в инспекторе)
|
||||
- FormerlySerializedAs (при переименовании полей, чтобы не ломать сериализацию)
|
||||
|
||||
Пример:
|
||||
```cs
|
||||
using UnityEngine;
|
||||
using UnityEngine.Serialization;
|
||||
|
||||
public sealed class Health : MonoBehaviour
|
||||
{
|
||||
[Header("Config")]
|
||||
[SerializeField, Range(1, 500)] private int _maxHp = 100;
|
||||
|
||||
[FormerlySerializedAs("_regenPerSec")]
|
||||
[SerializeField, Min(0f)] private float _regenPerSecond = 0f;
|
||||
|
||||
[ContextMenu("Print HP")]
|
||||
private void PrintHp()
|
||||
{
|
||||
Debug.Log($"HP: {_maxHp}");
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 6. Документация и комментарии
|
||||
|
||||
# 6. Документация и комментарии
|
||||
- XML-комментарии для публичного API.
|
||||
```cs
|
||||
/// <summary>
|
||||
/// Воспроизводит звуковой эффект.
|
||||
/// </summary>
|
||||
/// <param name="clip">Аудио-клип для воспроизведения.</param>
|
||||
/// <param name="position">Мировая позиция источника звука.</param>
|
||||
```
|
||||
- Комментарии «зачем», а не «что».
|
||||
```cs
|
||||
/// <summary>
|
||||
/// Воспроизводит звуковой эффект.
|
||||
/// </summary>
|
||||
/// <param name="clip">Аудио-клип для воспроизведения.</param>
|
||||
/// <param name="position">Мировая позиция источника звука.</param>
|
||||
public void PlayOneShot(AudioClip clip, Vector3 position)
|
||||
{
|
||||
// ...
|
||||
}
|
||||
```
|
||||
- Комментарии «зачем», а не «что».
|
||||
- Для сложных участков: короткие примеры использования (в README или рядом в комментариях), плюс ссылки на задачи/решения, если применимо.
|
||||
|
||||
# Git
|
||||
|
||||
## 1. База
|
||||
|
||||
1. Ветка `main`/`master` является основной веткой разработки. Прямые коммиты в `main`/`master` допускаются.
|
||||
2. История изменений должна обеспечивать однозначную интерпретацию причин и состава изменений, а также возможность оперативного отката.
|
||||
3. В `main`/`master` не допускается длительное нахождение состояния, при котором проект не собирается/не запускается. При фиксации некорректного состояния следующий коммит должен устранять выявленную неисправность.
|
||||
4. Один коммит должен соответствовать одной логической причине изменения. Смешивание независимых типов работ в одном коммите не допускается (например, рефакторинг совместно с добавлением функциональности).
|
||||
|
||||
## 2. Ограничения на состав репозитория
|
||||
|
||||
1. Нежелательно включение в репозиторий:
|
||||
- сборочных артефактов, кэшей, временных файлов, каталогов IDE/CI, иных генерируемых данных;
|
||||
- секретов (ключей, токенов, паролей), конфиденциальных данных, а также иных материалов, не предназначенных для публикации в истории Git.
|
||||
2. Для проектов с крупными бинарными ресурсами (в т.ч. геймдев) допускается и рекомендуется использование Git LFS для хранения соответствующих файлов.
|
||||
|
||||
## 3. Релизы и теги
|
||||
|
||||
1. Релизы подлежат фиксации тегами в формате `vX.Y.Z`
|
||||
2. Тег релиза должен ссылаться на коммит типа `RELEASE` либо на коммит, явно соответствующий релизному состоянию.
|
||||
|
||||
## 4. Требования к сообщениям коммитов
|
||||
|
||||
1. Сообщение коммита является обязательным документированием изменения и должно содержать:
|
||||
- тип коммита (далее — `TYPE`);
|
||||
- краткое описание на английском языке;
|
||||
- подробное описание на русском языке.
|
||||
2. Допускаются следующие значения `TYPE`:
|
||||
- `FEAT` — новая функциональность;
|
||||
- `RELEASE` — релиз/подготовка релиза;
|
||||
- `FIX` — исправление дефектов;
|
||||
- `UPDATE` — обновления зависимостей/конфигураций/версий без введения новой функциональности;
|
||||
- `TEST — тестовые/временные изменения для проверки/сборки;
|
||||
- `REFACTOR` — рефакторинг без изменения внешнего поведения;
|
||||
- `DOCS` — документация.
|
||||
3. Формат сообщения коммита устанавливается следующим образом:
|
||||
```diff
|
||||
<TYPE>: <Short summary in English (Можно по-русски)>
|
||||
|
||||
<Подробно по-русски>
|
||||
1. Что сделано
|
||||
2. Зачем / контекст
|
||||
3. Как проверить (при необходимости)
|
||||
4. Заметки (если есть)
|
||||
```
|
||||
## 5. Правила применения типов
|
||||
1. Коммиты `TEST` допускаются в `main`/`master`, при этом такие изменения подлежат удалению либо отключению до формирования релиза, если они не предназначены для выпуска.
|
||||
2. Коммиты `REFACTOR` должны не изменять пользовательское/внешнее поведение. Изменения поведения должны оформляться отдельными коммитами `FEAT`/`FIX`.
|
||||
## 6. Примеры сообщений коммитов
|
||||
|
||||
### FEAT
|
||||
|
||||
```diff
|
||||
FEAT: Add daily rewards system
|
||||
|
||||
Добавил ежедневные награды.
|
||||
- Логика расчёта награды по времени
|
||||
- Экран получения награды
|
||||
Проверка:
|
||||
1) Запустить игру
|
||||
2) Промотать время/симулировать новый день
|
||||
3) Убедиться, что награда выдаётся 1 раз в сутки
|
||||
```
|
||||
### TEST
|
||||
|
||||
```diff
|
||||
TESTBUILD: Add verbose logs for input issues
|
||||
|
||||
Временно добавил подробные логи для отладки ввода.
|
||||
- Логи на старте сцены и при событиях
|
||||
Заметка:
|
||||
- Удалить/выключить перед релизом.
|
||||
```
|
||||
|
||||
### RELEASE (+ тег vX.Y.Z)
|
||||
|
||||
```diff
|
||||
RELEASE: Release v1.3.2
|
||||
Релиз 1.3.2.
|
||||
- Исправлены вылеты на перезагрузке сцены
|
||||
- Обновлены зависимости
|
||||
Проверка:
|
||||
- Сборка проходит, тесты ок.
|
||||
```
|
||||
Loading…
x
Reference in New Issue
Block a user