Зачем хранить файл go.sum в git

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

Понимаете ли вы, чем go.sum отличается от go.mod и от lock-файлов других экосистем. Следом обычно спрашивают, что делать при конфликте в go.sum и как быть с приватными модулями.

Как отвечать

Начните с разделения ролей:

• go.mod выбирает версии: алгоритм минимального выбора версий (MVS) детерминированно вычисляет их из требований в go.mod. С Go 1.17 там перечислены и косвенные зависимости, нужные для сборки;
• go.sum проверяет содержимое: для каждой версии модуля он хранит криптографический хэш архива и отдельно хэш его go.mod (строки h1: и /go.mod h1:). Версии он не выбирает, поэтому это не lock-файл в смысле package-lock.json.

Зачем коммитить: при каждой загрузке модуля go сверяет хэш с go.sum. Если автор перезаписал тег, репозиторий подменили или прокси отдал другой архив, сборка упадёт с ошибкой проверки. Без go.sum в репозитории каждый прогон CI доверяет тому, что скачал прямо сейчас.

Второй слой защиты это база контрольных сумм sum.golang.org (переменная GOSUMDB): при первом добавлении зависимости хэш сверяется с публичным журналом. Для приватных модулей её отключают точечно через GOPRIVATE или GONOSUMDB, и тогда go.sum в репозитории остаётся единственной проверкой.

Практический довод: с Go 1.16 команды сборки по умолчанию работают в режиме -mod=readonly и не дописывают go.sum сами. Без файла CI упадёт с missing go.sum entry. Обновляют его go get и go mod tidy, а go mod verify проверяет, не изменились ли модули в локальном кэше после загрузки.

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

Называют go.sum списком зафиксированных версий. В нём бывают строки и для версий, которые в итоговую сборку не попали, а версии определяет go.mod.

При конфликте слияния удаляют файл целиком или правят его руками. Правильно принять обе стороны и прогнать go mod tidy.

Путают защиту целостности с защитой от уязвимостей. go.sum гарантирует, что код не подменили, но не спасёт, если вы сами обновились на версию с вредоносным кодом; уязвимости ищет govulncheck.