Як відкрити проект, чий сховище git в історії має авторські права?

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

Деталі:

• Код укладається під git. Ми зведемо все це назад в одну гілку до виходу.
• Є 400 Мб аудіоданих. Деякі файли мають музику, ліцензовану безкоштовно, наприклад, Jamendo, інші - MP3 з наших особистих колекцій.
• Незалежно від того, який підхід ми застосовуємо, ми завжди будемо зберігати незмінну копію оригінального репо, щоб не знищувати історію проекту.

Основне питання: Як поводитися з публічним релізом?

1. Видаліть всю історію проблемних файлів із сховища git та випустіть змінене репо. (v64 вказав спосіб зробити це.)
2. Крім того, можна зробити знімок поточного стану коду і навіть не турбуватися про те, що публікується код попереднього випуску.

Побічне питання: Як ми могли уникнути цієї дилеми в першу чергу, враховуючи, що інколи потрібен приватний код або засоби масової інформації для ранніх етапів проекту?

У GitHub є сторінка, яка пояснює, як викреслити файл із усієї історії: Видаліть конфіденційні дані .

Час від часу користувачі випадково вводять такі дані, як паролі чи ключі, у сховище git. Хоча ви можете використовувати git rmдля видалення файлу, він все ще буде в історії сховища. На щастя, git дозволяє досить просто видалити файл із усієї історії сховищ.

Небезпека: Після натискання на зобов’язання слід вважати, що дані є скомпрометованими. Якщо ви вчинили пароль, змініть його! Якщо ви ввели ключ, створіть новий.

Очистіть файл із вашого сховища

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

Побічне запитання: Як ми могли уникнути цієї дилеми в першу чергу, враховуючи, що інколи потрібен приватний код або засоби масової інформації для ранніх етапів проекту?

Якщо ви збираєтеся відслідковувати великі медіафайли (400 Мб аудіо), покладіть їх в окреме сховище.

Це вбиває двох птахів одним каменем:

1. Основне РЕПО на 400 МБ менше. (Люди не повинні завантажувати вміст у розмірі 400 Мб кожен раз, коли вони клонують.)
2. ЗМІ можуть бути приватними та зберігати окремо від усіх інших матеріалів. Тому не потрібно проводити додаткових робіт для випуску загальнодоступного сховища.

Якщо вам подобається, ви можете полегшити роботу, зробивши сховище медіа підмодуль публічного репо (який ви плануєте випускати).

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