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

Что проверяют

От разработчика ждут не знания команд, а рабочей модели: как вы ведёте ветку, как готовите изменения к ревью и что делаете, когда история разъехалась. В Go есть своя особенность: модули публикуются метками, и версия пакета берётся прямо из репозитория, поэтому небрежная работа с метками ломает сборку у всех, кто вас подключил.

Как отвечать

Опишите цикл от задачи до слияния.

Ветка от актуальной основной, небольшие осмысленные коммиты, приведение к свежей основе перед ревью. Скажите прямо, что делаете с историей: причёсываете ветку через git rebase -i до запроса на слияние и не трогаете уже опубликованную общую историю. Это ровно та граница, которую проверяют вопросом про rebase и merge.

Дальше конкретика, показывающая опыт:

• конфликты: смотрите обе стороны и общего предка, при повторяющихся слияниях помогает git rerere;
• поиск причины: git log -S по строке, git blame, git bisect для регрессии;
• восстановление: git reflog возвращает ветку после неудачного сброса, и это спасает чаще, чем кажется.

Про модули скажите отдельно: go.mod и go.sum коммитятся всегда, конфликт в них разрешается не правкой строк, а повторной командой обновления зависимостей; версия модуля задаётся меткой, а мажорные версии начиная со второй живут в отдельном пути импорта.

Где спотыкаются

Первое: не могут объяснить разницу между слиянием и перебазированием по существу. Довода о том, что так история чище, мало: важно, что перебазирование переписывает коммиты, поэтому опасно на ветке, с которой уже кто-то работает.

Второе: чинят go.sum руками. Конфликт в файле контрольных сумм разрешается пересборкой зависимостей, а не выбором понравившейся строки. Ручная правка даёт нерабочую сборку в чужом окружении.

Третье: одна ветка на всё и коммиты с сообщением из одного слова. Такую историю нельзя ревьюить, нельзя частично откатить и невозможно использовать для поиска причины регрессии.