> Расскажите о вашем опыте работы с Git (Go)

Короткий ответ

Git использую ежедневно в коммерческой разработке на Go: feature-branch workflow, code review через pull request, разрешение конфликтов, интерактивный rebase для чистой истории, работа с тегами и релизами. Уверенно работаю с cherry-pick, revert, stash, bisect для поиска регрессий. Знаю внутреннее устройство: объекты, refs, index, reflog. Настраивал хуки и автоматизацию через CI/CD пайплайны.

Подробное объяснение

Основной workflow - GitFlow или GitHub Flow в зависимости от проекта. В Go-проектах важна чистая история коммитов, так как она упрощает git bisect и аудит изменений. Использую conventional commits для автоматической генерации changelog.

Ключевые практики:

• атомарные коммиты: один логический change - один коммит
• понятные сообщения: fix: correct race condition in cache, feat: add retry middleware
• перед merge - rebase на актуальный main, чтобы избежать merge-коммитов
• защита main через branch protection rules: required reviews, status checks

Для Go специфично: перед коммитом всегда прогоняю gofmt, go vet, go test ./.... Это часть pre-commit хука. При работе с зависимостями слежу за go.mod и go.sum - конфликты в них решаю через go mod tidy.

На практике

Типичный сценарий: создаю ветку от актуального main, работаю, периодически делаю git fetch и rebase. Если конфликт - разрешаю вручную, затем git add и git rebase --continue. Перед push обязательно прогоняю тесты локально.

Для поиска регрессий использую git bisect run с командой go test ./.... Это сильно экономит время.

При работе в команде на Go-микросервисах часто приходится делать cherry-pick hotfix из release ветки в main. Для отмены неудачного merge использую git revert -m 1.

Из продвинутого: настраивал git worktree для параллельной работы над несколькими фичами без переключения контекста. Это удобно, когда нужно срочно пофиксить баг в production, не прерывая текущую задачу.

Пример кода

BASH
# Поиск регрессии через bisect
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run go test ./...

# Отмена merge-коммита
git revert -m 1 <merge-commit-hash>

# Интерактивный rebase для чистки истории
git rebase -i HEAD~5
# pick, squash, reword - по необходимости

# Worktree для параллельной работы
git worktree add ../hotfix -b fix/panic-on-nil

Как отвечать на собеседовании

Стройте ответ от простого к сложному: сначала базовые операции, затем workflow, затем продвинутые сценарии. Обязательно привязывайте к Go: упомяните go test в bisect, конфликты в go.mod, pre-commit хуки с линтерами.

Приводите конкретные ситуации из практики: как разрешали сложный конфликт, как откатывали неудачный релиз, как искали баг через bisect. Это показывает реальный опыт, а не заученные команды.

Если спросят про git reset vs git revert - объясните разницу: reset меняет историю, revert создаёт новый коммит. Для shared веток используйте только revert.

Что проверяет интервьюер

• Понимание distributed модели Git, а не просто заученные команды
• Умение работать в команде: code review, branch protection, разрешение конфликтов
• Навыки отладки: bisect, reflog, восстановление после ошибок
• Понимание trade-off между merge и rebase
• Практическое знание Go-специфики: зависимости, тесты, линтеры в контексте Git

Типичные ошибки

• Путаница между git pull --rebase и git pull - не объясняют, почему rebase предпочтительнее
• Использование git reset --hard без проверки reflog - можно потерять работу
• Неумение разрешать конфликты в go.mod / go.sum - просто удаляют файл вместо go mod tidy
• Слепое использование git commit -am без проверки staged изменений
• Отсутствие понимания разницы между HEAD, origin/main, FETCH_HEAD
• Слишком большие коммиты или коммиты с неработающим кодом - нарушение атомарности