---
name: git-init-workflow
title: Git Init Workflow
description: Всегда инициализировать git, проверять его наличие и поддерживать историю коммитов в любом проекте.
triggers:
  - Начало работы над новым проектом
  - Обнаружение отсутствия .git в рабочей директории
  - Просьба "сохранить" или "зафиксировать изменения"
  - Создание PROJECT.md или документации проекта
---

# Git Init Workflow

## Цель
Гарантировать, что **любой проект** имеет git-историю, понятные коммиты и документирование изменений.

## Шаги

### 1. Проверка наличия git

```bash
cd <PROJECT_DIR> && git status 2>/dev/null || echo "NO_GIT"
```

- Если вывод `NO_GIT` — переходим к шагу 2
- Если git есть — переходим к шагу 3

### 2. Инициализация репозитория

```bash
cd <PROJECT_DIR>
git init
git branch -m main      # или master, если проект старый
git config user.email "hermes@local"
git config user.name "Hermes Agent"
```

- Создать `.gitignore` для типичных артефактов (node_modules, .env, dist, build, *.log)
- Первый коммит с названием проекта:
  ```bash
  git add -A
  git commit -m "init: <название проекта>"
  ```

### 3. Проверка состояния рабочей директории

```bash
git status --short
```

- Если есть незакоммиченные изменения — коммитим

### 4. Фиксация изменений

Правила коммит-сообщений (Conventional Commits):
- `feat:` — новая фича
- `fix:` — исправление бага
- `docs:` — документация
- `refactor:` — рефакторинг
- `chore:` — рутина, конфиги
- `style:` — CSS/UI изменения
- `test:` — тесты

Формат:

```
<type>: <краткое описание на русском или английском>
```

Примеры:
- `feat: add booking form to trip page`
- `fix: nginx cookie secure header`
- `docs: update PROJECT.md with API endpoints`
- `refactor: extract useTrips hook`

Команды:

```bash
git add -A
git commit -m "<type>: <описание>"
```

### 5. Документирование проекта

- Создать `PROJECT.md` в корне, если его нет
- Включить: название, стек, структуру, пароли (если локально), историю изменений, команды сборки
- Закоммитить PROJECT.md отдельным коммитом: `docs: add PROJECT.md`

### 6. Проверка лога

```bash
git log --oneline -5
```

Убедиться, что коммиты понятные и история читаемая.

## Питфолы

- **Не коммить .env файлы** — всегда добавлять в .gitignore
- **Не коммить node_modules / dist / build** — это артефакты сборки
- **Не коммить большие бинарники** (фото, видео) — хранить вне git
- **Не делать коммиты без сообщений** — `git commit -m "..."` обязателен
- **Проверять git status перед каждым коммитом** — случайно не закоммитить лишнее
- **Если ветка не marketplace/main/master** — не переключать без явного запроса

## Примеры сценариев

### Сценарий: новый проект

```bash
mkdir /opt/new-project && cd /opt/new-project
... работа ...
git init && git branch -m main
echo "node_modules/\n.env\ndist/" > .gitignore
git add -A && git commit -m "init: new-project"
```

### Сценарий: сохранить текущую работу

```bash
cd /opt/sailor-bar
git status --short          # посмотреть что изменилось
git add -A                  # или git add <конкретные файлы>
git commit -m "feat: описание изменений"
git log --oneline -3        # проверить
```

### Сценарий: создание документации

```bash
после написания PROJECT.md
git add PROJECT.md
git commit -m "docs: add PROJECT.md with architecture and API"
```

## Верификация

- `git status` → nothing to commit, working tree clean
- `git log --oneline -5` → понятная история
- `ls -la .git` → репозиторий существует

## Инструменты для отладки и чтения кода

### Утиная отладка (Rubber Duck Debugging)
Метод, когда программист подробно, строчка за строчкой, объясняет логику своего кода игрушечной резиновой уточке на столе. В процессе объяснения решение проблемы почти всегда приходит само.

### Профилировщики (Profilers)
Вместо угадывания, почему программа тормозит, запускают профилировщик. Он строит «тепловую карту» кода и показывает, какая именно строчка съедает 90% памяти или времени процессора.