Модуль 04 — Git и GitHub/GitLab

Любая инфраструктура = код в Git. GitOps строится на Git. Code review через PR — основной workflow в команде.

Ментальная модель Git

Git — это не «облако» и не «backup». Это распределённая база данных коммитов, организованных в дерево (DAG).

Файлы в Git проходят 4 состояния:

working directory → staging area → local repo → remote (untracked / (git add) (git commit) (git push) modified) ← git reset ← git fetch ←

Базовый workflow

git init                          # инициализировать
git clone git@github.com:me/repo.git
git status                        # текущее состояние
git add .                         # добавить в staging
git diff                          # что изменилось (unstaged)
git diff --staged                 # что в staging
git commit -m "feat: add login"   # commit
git log --oneline --graph --all   # красивая история
git push origin main

Ветки

git branch                     # список
git switch -c feature/auth     # создать и переключиться (новый стиль)
git checkout -b feature/auth   # старый стиль (всё ещё работает)
git switch main                # переключиться
git merge feature/auth         # merge в текущую
git branch -d feature/auth     # удалить (если merged)
git branch -D feature/auth     # удалить принудительно

Merge vs Rebase ⭐

MergeRebase
ИсторияСохраняется как есть, появляется merge-commitЛинейная, как будто работа была последовательной
SHAНе меняетсяПереписывается (новые коммиты)
КогдаВ shared веткой (main, develop)На локальной feature-ветке перед PR
# на feature ветке: подтянуть свежий main
git switch feature/auth
git fetch origin
git rebase origin/main
# если конфликт: правишь файлы, git add, git rebase --continue

# interactive rebase — squash/edit/reorder коммитов
git rebase -i HEAD~3
Золотое правило rebase

Не делай rebase на ветке, которую кто-то ещё может использовать. Только на своих локальных feature-ветках. Иначе — переписанная история ломает работу команды.

Force push безопасно

После rebase ветка разошлась с remote. Чтобы запушить — нужен --force. НО если кто-то ещё пушил в эту ветку — ты сотрёшь его работу.

Решение: --force-with-lease. Push пройдёт только если remote — то, что ты ожидаешь.

git push origin feature/auth --force-with-lease   # ✓ безопасно
git push origin feature/auth --force              # ✗ опасно

Спасательный круг — reflog ⭐

«Я случайно удалил ветку!» «Я сделал hard reset и потерял коммиты!» — git reflog спасёт.

git reflog                          # история всех HEAD движений
# находишь нужный SHA
git checkout -b recovered <sha>     # восстановил

Reflog хранит изменения 90 дней по умолчанию. Это сейф под подушкой.

Stash, cherry-pick, bisect

git stash                       # отложить незакоммиченное
git stash list
git stash pop                   # вернуть и удалить из stash
git stash apply stash@{2}       # применить конкретный

git cherry-pick <sha>           # применить коммит из другой ветки

# bisect — бинарный поиск коммита, в котором что-то сломалось
git bisect start
git bisect bad                  # текущий коммит сломан
git bisect good v1.2.0          # этот тег работал
# Git предлагает коммит → проверяешь → говоришь good/bad
git bisect good                 # или bad
git bisect reset                # после нахождения

Workflow models

Trunk-based development ⭐ (современный стандарт)

Используют Google, Meta, Netflix.

GitHub Flow

Упрощённый: main → feature branch → PR → merge → деплой. Для большинства команд — оптимально.

GitFlow (устаревает)

develop, release, hotfix ветки. Раньше был стандартом — сейчас overhead для большинства проектов.

Conventional Commits + SemVer

Формат: type(scope): description

feat(auth): add OAuth login
fix(api): handle expired JWT tokens
docs(readme): update setup instructions
refactor(db): extract repository pattern
chore(deps): bump axios to 1.7.0
ci: add semgrep job

# BREAKING CHANGE
feat(api)!: change response format

BREAKING CHANGE: response now wraps data in 'result' field

Связь с SemVer: feat → minor (1.2.0), fix → patch (1.2.1), BREAKING → major (2.0.0).

Авто-генерация changelog: release-please, semantic-release.

Безопасность Git

Signed commits

GPG или SSH (с 2022+) подпись. На GitHub появляется значок Verified.

# SSH-подпись (проще GPG)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Pre-commit framework ⭐

Автоматические проверки перед каждым коммитом. pre-commit.com

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks                  # поиск секретов
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.92.1
    hooks:
      - id: terraform_fmt
      - id: terraform_validate
      - id: terraform_tfsec           # security scan
  - repo: https://github.com/koalaman/shellcheck-precommit
    rev: v0.10.0
    hooks:
      - id: shellcheck
  - repo: https://github.com/adrienverge/yamllint
    rev: v1.35.1
    hooks:
      - id: yamllint
pip install pre-commit
pre-commit install                  # подключить к .git/hooks
pre-commit run --all-files          # прогнать все файлы

Никогда не коммить

Если случайно закоммитил секрет — не просто удали в следующем коммите. Он остаётся в истории. Нужно:

  1. Немедленно отозвать секрет (rotation, revoke)
  2. Удалить из истории через git filter-repo или BFG Repo-Cleaner
  3. Force push (предупреди команду)

GitHub фишки

GitLab фишки

Best practices

  1. Маленькие коммиты, осмысленные сообщения. Не «fix», а «fix(auth): handle expired JWT»
  2. Один PR — одна задача. Не PR на 3000 строк
  3. Branch protection: требовать review + CI
  4. CODEOWNERS для разделения ответственности
  5. Pre-commit hooks с gitleaks
  6. Signed commits в командах с safety mindset
  7. Squash merge для PR с грязной историей

Anti-patterns

Чек-лист

  • ☐ Понимаю разницу merge и rebase
  • ☐ Знаю git reflog и могу восстановить ветку
  • ☐ Использую --force-with-lease
  • ☐ Conventional Commits — мой стандарт
  • ☐ Pre-commit hooks с gitleaks
  • ☐ Подписываю коммиты
  • ☐ Сделал хотя бы 1 PR в open-source

Лучшие источники

Git освоен. Теперь — БД (поверхностно).

Модуль 05 → Базы данных