Как открыть исходный код проекта, чей репозиторий git имеет защищенные авторским правом медиа в истории?

15

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

Детали:

Код версии под Git. Мы свернем все это обратно в одну ветку перед выпуском.
Есть 400 МБ аудиоданных. Некоторые файлы являются бесплатной музыкой, например, от Jamendo, другие - MP3 из наших личных коллекций.
Независимо от того, какой подход мы выберем, мы всегда будем сохранять неизменную копию исходного репо, чтобы не разрушать историю проекта.

Главный вопрос: как справиться с публичным релизом?

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

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

— хорошо относиться к своим модам
источник

13

GitHub имеет страницу, объясняющую, как удалить файл из всей истории: Удалить конфиденциальные данные .

Время от времени пользователи случайно фиксируют данные, такие как пароли или ключи, в git-репозитории. Хотя вы можете использовать git rmдля удаления файла, он все еще будет в истории хранилища. К счастью, git позволяет довольно просто удалить файл из всей истории репозитория.

Опасность: после того, как фиксация была нажата, вы должны считать данные скомпрометированными. Если вы ввели пароль, измените его! Если вы зафиксировали ключ, сгенерируйте новый.

Удалите файл из вашего хранилища

Теперь, когда пароль изменен, вы хотите удалить файл из истории и добавить его в, .gitignoreчтобы убедиться, что он не был случайно повторно зафиксирован. Для наших примеров мы собираемся удалить Rakefileиз хранилища гемов GitHub ...

— V64
источник

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

— хорошо относитесь к своим модам

@phyzome: Зависит от того, насколько важным вы считаете историю. Удалить команду довольно просто filter-branch- просто убедитесь, что она запущена на клоне репозитория, поскольку она разрушительна и не может быть отменена.

— Шарпи

8

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

Если вы собираетесь отслеживать большие медиа-файлы (400 МБ аудио), поместите их в отдельный репозиторий.

Это убивает двух зайцев одним выстрелом:

Основной репо на 400 МБ меньше. (Люди не должны загружать 400 МБ контента каждый раз, когда клонируют.)
Средства массовой информации могут быть конфиденциальными и храниться отдельно от всего остального. Таким образом, для освобождения публичного хранилища не требуется никакой дополнительной работы.

Если хотите, вы можете сделать работу с ней более удобной, сделав хранилище мультимедиа подмодулем публичного репо (который вы планируете выпустить).

Таким образом, вы просто сохраняете указатель на него, а не на (чувствительный) контент (для ранних этапов разработки). Затем, когда вы собираетесь опубликовать репозиторий публично, просто удалите ссылку на субмодуль, что гораздо менее хлопотно, чем переписывание вашей истории, чтобы отфильтровать вещи на 400 МБ.

— Алекс Будовски
источник