Comments 18

Что-то алгоритм какой-то странный. Уточнения:


Во-первых, добавлять файл в .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

Это не поможет избавиться от коммита физически. rebase не меняет существующие коммиты, он просто создаёт новые и переносит на них метку ветки. И старые коммиты останутся доступными по хэшу.
git rebase придётся делать на всех ветках, а вот filter-branch как раз и предназначен для внесения изменений во все ветки сразу

Учитывая, что пост рассматривает ситуацию с недавно отправленным файлом — не вполне понятно откуда возьмётся эта самая куча веток, для которых понадобятся изменения. Скорее всего, их там будет одна, максимум две.

Пост рассматривает разные случаи (ну или, по крайней мере, пытается это сделать). Для недавно отправленного файла, соглашусь, смысла нет. А вот для давнего — вполне.
Бороться надо всегда с причиной.

Такой проблемы в принципе нет, если с самого начала работы над проектом убедиться, что в .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 — это не просто система хранения, а система хранения исходников. Понятие "исходный код" как бы подразумевает, что он не обязан использоваться любыми инструментами напрямую.

Полностью запретить вряд ли получится, но можно сделать
git update-index --assume-unchanged — filename
Тогда гит не зальёт случайно изменения в историю коммитов.

Попробуйте не коммитить в репу мусор, а других карайте. А ещё есть сервисы хранения секретов, и без авторизованного доступа секреты не достать.

Добавлю три копейки. При работе с AWS никогда не храните ключи в исходниках и любых файлах проекта, которые вообще в принципе могут быть залиты в публичный репозиторий. По статистике боты пытаются логиниться с утекшими ключами спустя секунды после коммита в публичный репозиторий на github. Всегда настраивайте profiles и их используйте при удаленной работе.
Есть еще вот такая тулза, позволяет удалять текстовые файлы с определенным содержимым, расширением, либо превышающие какой-то заданный размер:
rtyley.github.io/bfg-repo-cleaner
Каждый разработчик когда-то по ошибке коммитил в общедоступный репозиторий файлы с конфиденциальной информацией.

Ни разу такого не делал. Всякие ключи храню в переменных окружения в памяти (и только в памяти). Код по необходимости достаёт их оттуда и использует. Закомитить их в git невозможно в принципе, поскольку как ты закомитишь туда блок ОЗУ неопределённого размера и адреса?
как вариант можно хранить ключи в репозитории зашифрованными, н-р. через ansible-vault
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
ruvds.com
Employees
11–30 employees
Registered

Habr blog