Git: Игнорировать файлы для публичного репозитория, но не для частного

Question

Я развертываю приложение Rails на Heroku (на данный момент) через git, а также хотел бы иметь общедоступную версию для людей, чтобы посмотреть.Некоторые файлы являются конфиденциальными и должны передаваться только в ветку «heroku», но не в ветку «public». Как лучше всего это сделать?

(я делаю знаю о переменных конфигурации Heroku, которая хороша как временное решение, но не весело, если икогда мне нужно переключить хосты.)

Две ветви не нужно синхронизировать постоянно - я согласен с тем, что периодически сливаю ветку «master» в ветку «public» и помещаю ее вgithub отдельно.

Я пробовал разные вещи:

• отдельные .gitignore файлы и "нашу" стратегию слияния - сначала это не сработало, а посленемного поработав с ним, я решил, что это становится слишком сложным, просто чтобы я мог выполнить, казалось бы, простую задачу

• , используя пользовательский файл exclude и добавив следующее к .git/config... это просто не работает:

.git / config

[branch "public"]
  excludesfile = +info/exclude_from_public

Каков наилучший способ иметь частный и общедоступный общий ресурс репозиториятот же код, но игнорировать важные файлы в публичном хранилище?

Выможет предположить, что ни один код не был зафиксирован или передан, то есть это заново инициализированный репозиторий.

(Этот вопрос задавался ранее в различных формах, но ни один из ответов не был прямым или ответы казались действительно хаки.Я просто здесь, чтобы спросить об этом очень простым способом и, надеюсь, получить очень простой ответ.

Answer 1

Я подпишу ответ подмодуля, но постараюсь дать некоторые пояснения.Во-первых, git работает не с файлами, а с коммитами.Невозможно отфильтровать файлы или пути в ветви, потому что ветка действительно является указателем на коммит.Когда вы исключаете или игнорируете, вы просто не позволяете файлам быть добавленными в ваш репозиторий.ни один из файлов «конфиденциальных файлов» даже не находится в репозитории, только в вашем рабочем каталоге.

Подмодуль - это просто ссылка на другой репозиторий, хранящийся в вашем репозитории, и конкретная фиксация, для которой извлечен репозиторий.отслеживание.Вы можете сказать обновление, используя

git submodule update --recursive sensitive-files

Чтобы упростить вещи, вы можете зафиксировать символические ссылки в нужном месте, указывая путь субмодуля.

ln -sf sensitive-files/shadow passwd

Затем добавьте символическую ссылку, как вы былюбой другой файл ..

Помните, что подмодуль - это просто извлеченный репозиторий git, вы можете легко ограничить доступ к этому фактическому репозиторию и сделать основной общедоступным.

Обновлено:

Извините, я пропустил уведомление, если вы все еще работаете над этим.

В вашем личном репозитории может быть несколько символических ссылок, ссылающихся на частный репозиторий (подмодуль), который извлекается в подкаталоге. Каждая база данныхили то, что используется экземпляром Rails, может быть символической ссылкой на этот частный подкаталог.

Кроме того, вам не нужно удаленное указание на частный репозиторий, просто запись в файле .gitmodules, которая автоматически поддерживается Подмодуль git .Вам все равно нужно защитить частный репозиторий, чтобы только ваш экземпляр Heroku мог получить к нему доступ.Для этого я бы предложил установить gitosis на сервере, если вы можете, или использовать какое-то другое решение для частного git-хостинга.Добавьте открытый ssh-ключ, соответствующий личному ключу вашего экземпляра, в список разрешенных пользователей.(Я не знаю, как это сделать в Heroku.)

Когда вы вносите изменения в heroku, он должен рекурсивно загружать все подмодули, упомянутые в хранилище.

Answer 2

Вы можете создать ловушку перед фиксацией в вашем локальном репо, здесь вы можете написать скрипт, чтобы проверить текущую извлеченную ветвь и удалить файлы-нарушители, если они присутствуют до обработки фиксации,Это позволяет избежать записи файлов в историю Git неправильной ветви.

#!/bin/bash
current_branch="$(git branch | sed -e 's/^*//')"
if [ $current_branch != "heroku" ]; then 
    // Delete sensitive files before commit
    rm -f dir1/dir2/exclude_from_public
    rm -f dir1/dir2/exclude_from_public_also
fi
exit 0

Кроме того, сценарий может просто проверить файлы и вернуть код завершения «1», уведомляя вас о невозможности продолжения фиксации.потому что он содержит конфиденциальные файлы.

Предостережение заключается в том, что вам нужно будет передать этот скрипт всем, кто работает над «привилегированной» веткой heroku, и всегда включать его в свой локальный репозиторий.

В идеале вы бы сделали эту проверку и на стороне сервера;но, к сожалению, GitHub предлагает только веб-вариант ловушки после получения, поэтому, если вы не являетесь владельцем собственного репо-хостинга, этот подход может быть реализован только локально.

Answer 3

Парень по имени Дэвид Альберт написал инструмент под названием Junk , чтобы решить почти точно эту проблему.Он позволяет файлам из отдельного хранилища «мусорных ящиков» жить рядом с файлами в вашем главном хранилище.

Личные файлы будут иметь отдельные коммиты от общедоступных, но это может сделать работу.

Answer 4

Вот некоторые другие вопросы и ответы StackOverflow в духе «как выполнить слияние, игнорируя некоторые файлы»:

• Git: объединение публичных и частных веток с сохранением определенных файлов в обеих ветках без изменений
• git merge должен игнорировать один каталог
• Как объединить отдельные файлы с помощью git-merge?
• Как заставить Git игнорировать файлы без использования .gitignore?
• Публичный и частный код в одном репозитории Git
• Как мне сказать git всегда выбирать мою локальную версию для конфликтующих слияний в конкретном файле?

Самое простое, что я могу придумать, это использовать alias 'ed слияние, которое удалит личные файлы перед выполнением коммита слияния. Это сработает, если вы готовы жить с слияниями без ускоренной перемотки. Вот alias:

git config alias.merge-master-exclude-private '!git merge --no-commit --no-ff master && (git diff --name-only HEAD..master | grep -f private_files | while read f; do git reset HEAD -- "$f"; rm -f "$f"; done; git commit -m "Merge master, excluding private files.")'

Затем отредактируйте файл private_files и добавьте шаблоны файлов, которые являются частными; например secret_file.*$. Вы можете заменить private_files в псевдониме на "$(git rev-parse --show-toplevel)"/private_files, чтобы прочитать private_files из каталога верхнего уровня.

Используйте git merge-master-exclude-private для объединения. Это выполнит объединение без ускоренной перемотки без фиксации, найдет файлы, соответствующие шаблонам, в файле private_files, reset индекс всех найденных личных файлов, удалит личные файлы в рабочем каталоге, затем подтвердит. Это должно обрабатывать файлы с пробелами в именах.

Если вы не хотите выполнять фиксацию, что дает вам возможность редактировать сообщение фиксации, удалите -m "Merge master, excluding private files." из псевдонима.

Answer 5

Один из способов сделать это - поместить ваши личные файлы в субмодуль и обратиться к этому модулю из вашего публичного репо.(В качестве альтернативы вы можете поместить свои публичные файлы в субмодуль и сослаться на это репо из своего частного репо.)

Answer 6

Создать 2 филиала.Одна ветвь с закрытыми файлами не будет передана в общедоступное хранилище.После объединения восстановите указанные файлы с помощью git checkout HEAD^ -- files that should not have been merged, rm other files, git add -A и git commit --amend -C HEAD.Я не уверен, какая разница в рассматриваемых файлах, но вы поняли.Сделайте небольшой сценарий для этого, и вы готовы.Вы могли бы даже зафиксировать список конфиденциальных файлов, который вы фиксируете в корне, и скрипт мог бы действовать от этого.

Answer 7

Похоже, что вы могли бы использовать mine.

По сути, он говорит Git избегать вещей в соответствии с соглашением <file or directory>_mine_, а сам инструмент дает вам * 1007Функции *, clean и restore, не полноценное управление версиями, но для личных вещей это прекрасно.

Все это довольно лаконично .

Answer 8

Я знаю, что это обходит вопрос, но у меня просто было бы два репозитория git. Затем вы можете просто добавить их навсегда в список игнорирования в общедоступном репозитории.

Вы можете иметь второй репозиторий для личных файлов и небольшой скрипт для копирования изменений в правильное расположение в производственной системе при выполнении развертывания.

Это снижает риск того, что когда вы отправитесь в отпуск и новый стажер обновит публичное репо, ваша личная информация будет случайно утечка. ; -)