.webp)
.webp)
Подготавливаем файлы, добавляем сообщение фиксации, загружаем файл. Нет, подождите! Это не тот файл. Кажется, пришло время гуглить.
Каждый разработчик хотя бы раз за свою практику случайно фиксировал конфиденциальные файлы. Итак, как же исправить эту ситуацию и убедиться в том, что такого больше не произойдет?
В этой статье я расскажу вам, что делать, если вы вдруг случайно зафиксировали конфиденциальный файл, а также продемонстрирую вам команды Git, с помощью которых можно вносить правки в историю.
Как удалить файлы конфиденциальных данных из Git
Устранение последствий
Итак, вы случайно зафиксировали конфиденциальный файл. Назовем его .env. Есть два немаловажных вопроса, на которые вам нужно ответить:
- Вы добавили коммит в удаленный репозиторий? и
- Является ли удаленный репозиторий общедоступным?
Еще не добавил
Если вы еще не успели добавить файл в репозиторий, то ситуация не совсем критичная. Вы можете просто вернуться к предыдущему снимку состояния проекта:
git reset HEAD^ --softВаши файлы останутся в рабочей копии, и у вас будет возможность исправить конфиденциальный файл/информацию. Если вы хотите оставить коммит и просто удалить конфиденциальный файл, то вам нужно выполнить следующие команды:
git rm .env --cached
git commit --amendЕсли это был последний коммит, то вы можете воспользоваться флагом --amend. Если вы уже успели поверх добавить еще кучу коммитов, то вам нужна другая команда:
git rebase -i HEAD~{how many commits to go back?} //{сколько коммитов добавлено после?}Таким образом вы сможете исправить неправильный коммит и после внесений изменений воспроизвести все остальные, так что вы их не потеряете.
Уже добавил
Если вы уже успели добавить файл в репозиторий, то здесь есть важное отличие между общедоступными и частными репозиториями.
Если ваш репозиторий является частным, и в нем нет ботов или людей, у которых нет к нему доступа, то вы можете с легкостью изменить последний коммит с помощью двух команд, приведенных выше.
Если вы успели добавить кучу коммитов поверх ошибочного, то вы в любом случае для того, чтобы удалить конфиденциальный файл из истории Git, можете воспользоваться командой filter-branch или устройством очистки репозитория BFG:
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --allНо помните о двух важных аспектах таких изменений:
- Вы на самом деле меняете историю.
Если есть другие люди, другие ветки проекта, другие ответвления кода или открытые запросы на внесение изменений, которые зависят от текущего состояния репозитория, то вы окажете на них негативное воздействие. В таких ситуациях обращайтесь с репозиторием так, как будто он общедоступный и избегайте внесения изменений в историю.
- Вам нужно очистить кэш.
Вам нужно обратиться в службу поддержки вашего поставщика хранилища Git с просьбой очистить кэш вашего репозитория. Даже если вы исправили ошибочный коммит или переписали историю, старый коммит с конфиденциальным файлом все равно останется в кэше. Чтобы получить доступ к нему, вам нужно знать его идентификатор, но он все еще будет доступен до тех пор, пока вы не очистите кэш.
Нужно ли повторно генерировать ключи, если файл был добавлен в общедоступный репозиторий?
В общем, да. Если ваш репозиторий является общедоступным или если вы не считаете, что он является безопасным по какой-то иной причине, вы должны учесть вероятность того, что конфиденциальная информация может быть скомпрометирована с точки зрения безопасности.
Даже если вы удалите данные из своего репозитория, вы все равно ничего не сможете сделать с ботами и другими ответвлениями репозитория. Итак, что же делать дальше?
- Деактивировать все ключи и/или пароли
Это должен быть ваш первый шаг. Как только вы деактивируете ключи, конфиденциальная информация станет бесполезной.
- Настройте gitignore
Добавьте все конфиденциальные данные в .gitignore, чтобы у Git не было возможности ее отслеживать.
- Удалите конфиденциальный файлы
- Зафиксируйте исправления вместе с содержательным обоснованием
Не пытайтесь скрыть ошибку. Другие люди, с которыми вы совместно работаете, и вы сами через месяц будете признательны тому, что у вас есть обоснование того, что произошло и как был исправлен этот коммит.
Рекомендации по хранению конфиденциальных данных в Git
Для того, чтобы избежать таких ситуацию в будущем, ниже я привел несколько советов по хранению конфиденциальных данных:
Храните конфиденциальные данные в файле .env (или в аналогичных файлах на других платформах)
Храните ключи API и другие конфиденциальные данные в отдельном файле .env. Тем самым вы не сможете случайно зафиксировать новый ключ, но при этом файл .env должен быть исключен из Git.
Еще одно огромное преимущество – вы можете получить доступ ко всем ключам с помощью одной глобальной настраиваемой переменной.
Используйте по возможности API ключи
API-ключи легко генерировать и деактивировать, если они вдруг были скомпрометированы. По возможности используйте именно их и избегайте использования учетных данных/паролей.
Добавьте ключи API в свою систему сборки
Ключи API, как правило, требуются в процессе сборки приложений. Системы сборки, такие как Netlify, позволяют добавлять эти ключи в безопасные зоны своей администрации. Эти ключи будут автоматически внедрены в ваше приложение через глобальную настраиваемую переменную.
Добавьте файл .env в gitignore
Убедитесь, что Git не отслеживает файлы, которые содержат конфиденциальную информацию.
Предоставьте файл .env.template
Файл шаблона сообщает другим участникам совместной работы, что необходимо добавить нужные ключи API, не заставляя их читать длинные документы.
Не менять историю на удаленном репозитории
Считайте, что это эмпирическое правило. Если вы следовали всем правилам, которые были приведены выше, то вам и не придется вносить какие-то изменения в историю.
