Шпаргалка по Git

26 мая 2026 г.от txtly

Git — распределённая система контроля версий. Каждый разработчик имеет полноценный локальный репозиторий. Для обмена изменениями используются git push и git pull.

В этой шпаргалке собраны не только базовые команды, но и продвинутые техники логирования, правила чистой истории и стандарты оформления коммитов, включая форматы, используемые ИИ-агентами.

Основы

# Клонировать репозиторий
git clone git@github.com:user/repo.git ./

# Проверить статус
git status

# Просмотр истории (базовый)
git log --oneline --graph --all

# Добавить изменения
git add file.txt          # конкретный файл
git add .                 # все изменения
git add -p                # интерактивно

# Коммит
git commit -m "сообщение"
git commit --amend        # изменить последний коммит

Продвинутое логирование

Чтобы узнать, кто, когда и какие файлы менял, а также оценить объем работы, используйте расширенные опции git log.

Анализ изменений конкретного пользователя за период

# Все коммиты пользователя за последнюю неделю
git log --author="Имя Пользователя" --since="1 week ago" --oneline

# Коммиты пользователя за конкретный период
git log --author="user@example.com" --after="2026-05-01" --before="2026-05-31"

# Детальный вывод: какие файлы менял и сколько строк добавлено/удалено
git log --author="Имя Пользователя" --since="1 month ago" --stat

# Подробная статистика по всем файлам, которые трогал пользователь
git log --author="Имя Пользователя" --since="1 month ago" --numstat

# Суммарная статистика: количество добавленных и удаленных строк пользователем
git log --author="Имя Пользователя" --since="1 month ago" --shortstat --oneline

Просмотр изменений в конкретном файле

# История изменений файла с подсветкой различий
git log -p -- path/to/file.txt

# Кто и когда менял конкретные строки в файле (как git blame, но для истории)
git log -L 10,50:path/to/file.py

Создание отчета по коммитам для код-ревью

# Компактный лог с графом, ветками, авторами, датами и описанием коммитов
git log --graph --pretty=format:'%C(yellow)%h%C(reset) -%C(auto)%d%C(reset) %s %C(blue)(%an, %ar)%C(reset)' --all

# Сводка по изменениям в виде "кто, что и сколько раз менял" в указанной папке
git shortlog -sne --all -- src/

# Лог в машиночитаемом формате JSON (требуется доп. инструмент или скрипт, но основа — кастомный формат)
git log --pretty=format:'{%n  "commit": "%H",%n  "author": "%an",%n  "date": "%ad",%n  "message": "%s"%n},'

Ветки

# Список веток
git branch                # локальные
git branch -a             # все (включая remote)

# Создать и переключиться на новую ветку
git checkout -b feature/new-feature

# Переключиться на существующую ветку
git checkout main

# Создать ветку и сразу опубликовать её
git checkout -b dev
git push origin dev

# Выписать существующую ветку с remote
git checkout --track origin/production

# Удалить локальную ветку
git branch -d feature/old

# Удалить remote-ветку
git push origin --delete feature/old

Git stash: припрятываем изменения

Ситуация: вы работаете над задачей, и срочно нужно переключиться на другую ветку или подтянуть свежие изменения. Чтобы не делать незаконченный коммит, используйте stash.

# Сохранить незакоммиченные изменения и очистить рабочую директорию
git stash

# Получить последние сохраненные изменения обратно и удалить их из стека
git stash pop

# Наложить изменения из стека, но не удалять их оттуда
git stash apply

# Посмотреть список всех "тайников"
git stash list

# Просмотреть содержимое конкретного тайника (последнего или по индексу)
git stash show -p
git stash show -p stash@{1}

# Удалить конкретный тайник
git stash drop stash@{0}

# Очистить весь стек
git stash clear

Синхронизация, слияние и чистая история с rebase

Ключевая практика в команде — избегать лишних merge-коммитов и держать историю линейной.

Классический подход (с merge-коммитом)

git pull origin main   # создает merge-коммит, если локальная и удаленная ветки разошлись

Правильный командный подход (rebase вместо merge)

Ваши коммиты всегда должны быть "поверх" последних изменений из основной ветки.

# 1. Сохраняем незавершенную работу
git stash

# 2. Забираем все изменения из удаленного репозитория (без слияния с вашей веткой)
git fetch origin

# 3. Пересаживаем вашу текущую ветку поверх актуальной удаленной
git rebase origin/main

# 4. Возвращаем незавершенную работу
git stash pop

# Или то же самое одной командой при pull:
git pull --rebase origin main

Работа в feature-ветке перед созданием Pull Request

# Создаем ветку для фичи
git checkout -b feature/new-cool-stuff

# ... работаем, делаем коммиты ...

# Когда фича готова, "причесываем" историю
git fetch origin
git rebase origin/main     # Пересаживаем фичу на актуальный мейн

# Опционально: склеиваем черновые коммиты в один логический
git rebase -i HEAD~3

# Пушим ветку. Если до этого она уже была запушена, потребуется force-push.
git push --force-with-lease origin feature/new-cool-stuff

# Создаем Pull Request в main.
# После слияния PR удаляем ветку:
git checkout main
git pull origin main
git branch -d feature/new-cool-stuff

Важно: git rebase переписывает историю. Используйте его только для своих локальных веток, которые ещё не слиты в общие (main, develop).

Откат изменений

# Отменить незакоммиченные изменения в файле
git checkout -- file.txt

# Убрать файл из staging
git reset HEAD file.txt

# Откатить последний коммит (сохраняя изменения незакоммиченными)
git reset --soft HEAD~1

# Откатить последний коммит (полностью удаляя изменения)
git reset --hard HEAD~1

# Создать новый коммит, отменяющий изменения старого (безопасно для общих веток)
git revert abc1234

Работа с тегами

# Создать легковесный тег
git tag v1.0.0

# Создать аннотированный тег (рекомендуется для релизов)
git tag -a v1.0.0 -m "Релиз версии 1.0.0"

# Отправить теги в удаленный репозиторий
git push origin v1.0.0
git push origin --tags

# Удалить тег локально и удаленно
git tag -d v1.0.0
git push origin --delete v1.0.0

Решение конфликтов

При конфликте слияния или rebase файл содержит маркеры конфликта:

<<<<<<< HEAD
ваша версия (текущая ветка)
=======
версия из сливаемой ветки
>>>>>>> feature/branch

Алгоритм действий:

Найдите все файлы с конфликтами: git status.
Вручную отредактируйте файлы, оставив нужный код и удалив маркеры <<<, ===, >>>.
Добавьте исправленные файлы: git add <file>.
Продолжите прерванную операцию:
- Если был merge — git commit.
- Если был rebase — git rebase --continue.

Правила хорошего тона

Пишите осмысленные сообщения коммитов. Следуйте стандарту (см. ниже).
Один коммит — одна логическая единица. Не смешивайте рефакторинг и новую фичу в одном коммите.
Держите историю чистой. Используйте git pull --rebase вместо git pull.
Причесывайте feature-ветки перед PR. Делайте git rebase на актуальную основную ветку и склеивайте черновые коммиты (git rebase -i).
Не force-push в общие ветки. Для обновления своей feature-ветки используйте безопасный git push --force-with-lease.
Удаляйте слитые ветки. И локально, и на сервере.
Не коммитьте сгенерированные файлы и артефакты. Используйте .gitignore.
Проверяйте изменения перед коммитом. git diff --staged, git add -p.

Стандарты оформления коммитов

1. Широко применяемые форматы

Conventional Commits (самый популярный) Формат: <тип>[необязательная область]: <краткое описание>

feat(auth): add OAuth2 login support
fix(parser): resolve null pointer exception on empty input
docs(readme): update installation guide
chore(deps): bump lodash to 4.17.21
BREAKING CHANGE: API endpoint /v1/login replaced with /v2/auth

Формат Angular Похож на Conventional Commits, но с более строгой структурой. Заголовок до 50 символов, тело и подвал отделяются пустой строкой.

feat($compile): add source map support

Added source map support to the compiler.
Source maps can now be generated for debugging.

Closes #456
BREAKING CHANGE: The compiler API now requires a `sourceMap` option.

Стиль Linux Kernel Использует заглавную подсистему и императив в описании.

subsystem: краткое описание того, что делает коммит

Более детальное объяснение того, что и почему было сделано.
Может занимать несколько строк.

Signed-off-by: Имя Автора <email@example.com>

2. Форматы для ИИ-агентов и автоматизации

Все чаще в разработке используются ИИ-ассистенты (Copilot, Cursor, Aider, Cline). Они генерируют стандартизированные сообщения, упрощающие логирование и автоматический чейнджлог.

Aider AI Commit Format Использует флаг --ai-commit для генерации сообщений на основе диффа. <тип>: <краткое описание>

Типы: feat, fix, refactor, docs, test, chore, perf, style.

feat: add user profile editing endpoint
fix: correct typo in environment variable name
refactor: extract pagination logic into reusable module

Cline (VS Code Extension) Commit Format Генерирует сообщение в формате Conventional Commits с подробным телом, сгенерированным моделью.

feat: реализовать OAuth авторизацию через Google

- Добавлен модуль google-auth с OAuth2 flow
- Интегрирована кнопка "Войти через Google" на странице логина
- Обновлена модель User для хранения googleId

Auto-semver Bots (например, release-please) Эти боты анализируют коммиты для автоматического определения следующей версии. Они строго требуют формат Conventional Commits.

fix: ... -> патч-версия (1.0.0 -> 1.0.1)
feat: ... -> минорная версия (1.0.1 -> 1.1.0)
feat!: ... или BREAKING CHANGE: -> мажорная версия (1.1.0 -> 2.0.0)

Языки программирования Шпаргалки

разработка