Git workflow для Go разработчиков: от хаоса к чистому коду

Почему Git workflow — это боль каждого Go-разработчика?

Вы когда-нибудь тратили полдня на то, чтобы разобраться, почему в master ветке сломался билд, хотя вчера всё работало? Или путались в версиях Go-модулей, когда два разработчика одновременно правили один пакет? Знакомо? Добро пожаловать в клуб.

Go — язык простой и элегантный. Но без правильного git workflow для Go разработчиков даже самый чистый код превращается в лапшу. В этой статье мы разберем не абстрактные теории, а реальные сценарии: как работать с go modules, как не сломать CI/CD и как сделать code review быстрым и полезным. Пристегнитесь, будет практично.

Основа основ: Git Flow и его адаптация под Go

Классический Git Flow (ветки main, develop, feature/*, release/*, hotfix/*) отлично работает для больших проектов. Но в мире Go есть нюансы.

Почему Trunk-Based Development часто побеждает?

Go-сообщество любит простоту. Trunk-Based Development (работа в одной основной ветке с короткоживущими feature-ветками) идеально сочетается с философией Go. Меньше веток — меньше головной боли с мержами. Для небольших команд (до 5 человек) это часто лучший выбор.

Однако, если у вас релизный цикл 2 недели и несколько параллельных фич — Git Flow остаётся королём. Просто помните: каждая ветка должна жить не дольше 2-3 дней. Иначе конфликты неизбежны.

# Пример создания feature-ветки для новой middleware
git checkout -b feature/add-request-logger
# Работаем, коммитим, пушим
git push origin feature/add-request-logger
# После code review — squash и мерж в main

Go Modules и Git: Как не сойти с ума

Самая частая проблема в golang git workflow — это зависимости. Go Modules (начиная с Go 1.11) решили многие проблемы, но добавили новые.

Правильная работа с тегами

Ваш модуль — это публичный API. Если вы меняете его, меняйте версию. Семантическое версионирование (semver) — это не просто модно, это обязательно.

• v0.x.x — нестабильная версия, можно ломать совместимость.
• v1.x.x — стабильная, обратная совместимость обязательна.
• v2+ — мажорные изменения, обязательно меняйте путь модуля.

Пример правильного тегирования:

git tag v1.2.3
git push origin v1.2.3

А теперь пример, как делать НЕ надо:

# Плохо: тег без синхронизации с go.mod
git tag v1.0.0
# А в go.mod всё ещё версия v0.5.0

Всегда сначала обновляйте go.mod, потом ставьте тег. Иначе go get сойдет с ума.

Как обновлять зависимости в команде

Допустим, вы обновили библиотеку github.com/gin-gonic/gin. Вместо того чтобы пушить огромный дифф, следуйте правилу: один коммит — одно изменение.

# Обновляем одну зависимость
go get github.com/gin-gonic/gin@v1.9.1
go mod tidy
git add go.mod go.sum
git commit -m "chore: update gin to v1.9.1"
git push

Это упрощает code review: коллега видит ровно то, что изменилось, а не «магию» в go.sum.

Code Review для Go: Git workflow на страже качества

Code review — это не про «найди баги». Это про передачу знаний и поддержание стиля. Но если ваш git workflow для golang проектов не настроен, ревью превращается в ад.

Как сделать review быстрым

• Маленькие PR: 200-300 строк кода — максимум. Больше — разбивайте.
• Автоматический линтинг: golangci-lint должен работать до ревью, а не после. Настройте pre-commit hook или CI.
• Единый стиль: используйте gofmt (да, это обязательно). Никаких споров про отступы.

Пример pre-commit hook для Go:

#!/bin/sh
# .git/hooks/pre-commit
echo "Running gofmt..."
unformatted=$(gofmt -l .)
if [ -n "$unformatted" ]; then
    echo "Please run gofmt on:"
    echo "$unformatted"
    exit 1
fi

echo "Running go vet..."
go vet ./...
if [ $? -ne 0 ]; then
    exit 1
fi

Сделайте файл исполняемым: chmod +x .git/hooks/pre-commit. И всё — половина замечаний на ревью отпадёт сама собой.

Структура коммитов в Go-проекте

Используйте Conventional Commits. Это не просто модно, это упрощает генерацию changelog'ов и поиск ошибок через git bisect.

• feat: add user authentication middleware
• fix: correct timeout in HTTP client
• chore: update go.mod dependencies
• docs: add examples to README

Почему это важно для Go? Потому что go test ./... и CI/CD часто привязаны к конкретным коммитам. Читаемый коммит — спасение при откате.

CI/CD для Go: Автоматизируем рутину

Хороший git workflow для go разработчиков немыслим без автоматизации. Вот минимальный набор, который должен быть в каждом проекте:

Что должно делать CI при каждом пуше?

1. go build ./... — проверка, что код компилируется.
2. go test ./... -race — тесты с детектором гонок.
3. golangci-lint run — линтинг по правилам команды.
4. go mod verify — проверка целостности модулей.

Пример простого GitHub Actions workflow для Go:

# .github/workflows/ci.yml
name: Go CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Set up Go
      uses: actions/setup-go@v5
      with:
        go-version: '1.22'
    - name: Build
      run: go build ./...
    - name: Test
      run: go test ./... -race -coverprofile=coverage.txt
    -