> а какие существуют способы защиты от подобной случайной публикации?Организационные меры. Например, надо взять за правило, выполнять на рабочих серверах исключительно git pull. Ну, можно ещё что-нибудь -- там есть над чем подумать, и что выбрать -- но из тех команд, которые работают с origin, только pull. И шелл туда дать только сертифицированным сотрудникам. Соответственно в этот рабочий репозиторий не следует вносить никаких изменений текстовым редактором. А если они внесены, то перетаскивать в development версию патчами.
Эти правила, при желании, энфорсятся патченным git в системе, который просто не умеет в push. Хотя программисты ребята прошаренные, они на другом компе git pull сделают, а потом перешлют в github... Чтобы они таких гадостей не делали бы принудительно, придётся более сложные патчи на git накладывать... Но, с другой стороны, если программисты настолько невменяемы, что не могут следовать ТБ, то их следует уволить и нанять других.
Такая штука, как, например, электрик, не соблюдающий ТБ, долго не живёт. Поэтому подавляющее большинство электриков соблюдает ТБ. А вот программиста, за кривой git push не убивают, что катастрофически сказывается на естественном отборе и позволяет выживать полным долбонавтам. Но если серьёзно заняться внедрением ТБ, регулярно мониторить ситуацию (точнее иррегулярно, по непредсказуемому графику, но достаточно часто), и безусловно лишать премии за однократный залёт в деле нарушения ТБ, а за второй-третий в течение года увольнять, то все быстро проникнутся идеей.
Тут проблема даже не в том, что сложно сохранить в тайне ключи и не опубликовать их нечаянно. Проблема в том, что организация вырабатывает весь workflow начиная с момента создания этой организации. В момент создания сложный workflow и кучерявая ТБ выглядят оверхедом -- над кодом работает три человека, все они высококвалифицированы и они сами создавали этот workflow, -- они с малой вероятностью совершат утечку данных, и им на старте компании очень важно минимизировать всю "бюрократию" и действовать максимально эффективно. Но со временем компания разрастается, в ней появляется множество менее квалифицированных ребят, и более того, даже квалифицированные далеко не все понимают, что и где происходит, и какое их неловкое движение приведёт к факапу. Была замечательная история про парня, который сразу после ВУЗа устроился программером, пришёл работать первый день, ему дали бумажку, согласно которой он должен был настроить своё рабочее место, в частности подключение к базам. Он что-то в этой бумажке не так понял, не то вбил в консольку, и удалил все таблички из продакшна. Его спешно уволили, типа раз он это сделал, значит он виноват. Но писечка в том, что виноват менеджмент, который не предвидел возможность подобного, и не изменил сооветствующим образом весь workflow.
С публикацией приватных данных в github та же ситуация. На определённом этапе развития компании ей следовало пересмотреть своё отношение к тому, как организованы все потоки данных внутри инфраструктуры компании и за её пределы. Но менеджеры действовали по принципу "работает, не трожь", и в результате они получили то, что получили.
