Комментарии 19
Что-то алгоритм какой-то странный. Уточнения:
Во-первых, добавлять файл в .gitignore и делать git rm --cached придётся во всех ветках, не вполне понятно почему иногда об этом упомянуто, а иногда нет.
Во-вторых, вместо простого git rebase -i HEAD~{...}, возможно, лучше cделать так:
git commit --fixup HEAD~{...}
git rebase -i --autosquash HEAD~{...}В-третьих, не вполне понятно почему для уже опубликованной истории предлагается делать git filter-branch, если git rebase -i в большинстве случаев прекрасно работает (а меньшинство случаев, скорее всего, пойдёт по ветке "Consider the API key compromised")
В-четвёртых, в "нижней" ветке забыли сделать git push --force-with-lease
Такой проблемы в принципе нет, если с самого начала работы над проектом убедиться, что в .gitignore добавлены файлы вида .env и ему подобные.
Еще можно секреты вынести в отдельную папку и вообще весь ее контент добавить в .gitignore для предотвращения тех редких ситуаций, когда внезапно понадобилось создать еще один файл с секретной информацией и его название не подходит под существующие правила игнорирования.
А всё остальное, это уже следствие написания кода не приходя в сознание.
Очень хочу возможность запрет на commit определенных файлов, при том что они продолжали бы получать обновления с сервера.
Основная проблема хранения настроек, что нельзя положить один общий файл для всех и перекрывать несколько свойств у каждого.
А кто мешает научить программу работать с несколькими файлами конфигурации?
Тот же ASP.NET Core, к слову, по умолчанию читает свою конфигурацию аж из 4х источников — из переменных окружения, из appsettings.json, из appsettings.{env}.json, и (в dev-режиме) из особых user secrets, которые вообще в папке проекта не хранятся.
Ну или вернёмся к node js и env-файлам. Никто же не мешает сделать вот так:
// config.mjs
export const foo = process.env.FOO ?? 'default foo value';
export const bar = process.env.BAR ?? 'default bar value';
Полностью запретить вряд ли получится, но можно сделать
git update-index --assume-unchanged — filename
Тогда гит не зальёт случайно изменения в историю коммитов.
Запрет коммита файла и при этом получение обновлений файла с сервера это оксюморон. Невозможно обновить файл в репозитории без предварительного добавления его туда коммитом.
Но файл .env.template прекрасно решает проблему с хранением и обновлением шаблона. Это и будет общим файлом.
Трюк с --assume-unchanged только усложняет рабочий процесс, так как придётся руками это делать в каждом локальном репозитории и следить чтобы оно не сбросилось.
Попробуйте не коммитить в репу мусор, а других карайте. А ещё есть сервисы хранения секретов, и без авторизованного доступа секреты не достать.
rtyley.github.io/bfg-repo-cleaner
Каждый разработчик когда-то по ошибке коммитил в общедоступный репозиторий файлы с конфиденциальной информацией.
Ни разу такого не делал. Всякие ключи храню в переменных окружения в памяти (и только в памяти). Код по необходимости достаёт их оттуда и использует. Закомитить их в git невозможно в принципе, поскольку как ты закомитишь туда блок ОЗУ неопределённого размера и адреса?
Как убрать из Git-репозитория файлы с конфиденциальной информацией