Comment open-source un projet dont le référentiel git a des médias sous copyright dans l'histoire?

Je souhaite publier un projet de logiciel d'empreintes digitales audio sous une licence gratuite, mais le référentiel contient des fichiers audio protégés par des droits d'auteur. Les cas de test utilisent également actuellement ces fichiers. Comment puis-je divulguer le code au public avec un historique de version maximal mais sans violer les droits d'auteur?

Détails:

• Le code est versionné sous git. Nous allons tout replier dans une seule branche avant la sortie.
• Il y a 400 Mo de données audio. Certains fichiers sont de la musique sous licence libre, par exemple de Jamendo, d'autres sont des MP3 de nos collections personnelles.
• Quelle que soit l'approche que nous adoptons, nous conserverons toujours une copie immuable du dépôt d'origine, afin de ne pas détruire l'historique du projet.

Question principale: comment gérer la diffusion publique?

1. Supprimez tout l'historique des fichiers en question du référentiel git et libérez le dépôt modifié. (La v64 a indiqué un moyen de procéder.)
2. Alternativement, prenez un instantané de l'état actuel du code et ne prenez même pas la peine d'avoir un historique public du code de pré-version.

Question secondaire: Comment aurions-nous pu éviter ce dilemme en premier lieu, étant donné que parfois du code ou des médias privés sont nécessaires pour les premières étapes d'un projet?

GitHub a une page expliquant comment effacer un fichier de tout l'historique: Supprimer les données sensibles .

De temps en temps, les utilisateurs commettent accidentellement des données comme des mots de passe ou des clés dans un référentiel git. Bien que vous puissiez utiliser git rmpour supprimer le fichier, il sera toujours dans l'historique du référentiel. Heureusement, git simplifie la suppression du fichier de l'historique complet du référentiel.

Danger: une fois le commit poussé, vous devez considérer que les données sont compromises. Si vous avez commis un mot de passe, changez-le! Si vous avez validé une clé, générez-en une nouvelle.

Purger le fichier de votre référentiel

Maintenant que le mot de passe a été modifié, vous souhaitez supprimer le fichier de l'historique et l'ajouter au .gitignoreafin de vous assurer qu'il n'est pas réaffecté accidentellement. Pour nos exemples, nous allons supprimer Rakefiledu référentiel de gemmes GitHub ...

Question secondaire: Comment aurions-nous pu éviter ce dilemme en premier lieu, étant donné que parfois du code ou des médias privés sont nécessaires pour les premières étapes d'un projet?

Si vous souhaitez suivre de gros fichiers multimédias (400 Mo d'audio), placez-les dans un référentiel séparé.

Cela tue deux oiseaux avec une pierre:

1. Le dépôt principal est plus petit de 400 Mo. (Les gens n'ont pas à télécharger 400 Mo de contenu à chaque fois qu'ils clonent.)
2. Les médias peuvent être privés et séparés de tous les autres éléments. En tant que tel, aucun travail supplémentaire ne doit être effectué pour libérer le référentiel public.

Si vous le souhaitez, vous pouvez le rendre plus pratique à utiliser en faisant du référentiel multimédia un sous - module du référentiel public (que vous prévoyez de publier).

De cette façon, vous gardez simplement un pointeur vers lui, pas le contenu (sensible) lui-même (pour les premiers stades de développement). Ensuite, lorsque vous allez publier le référentiel publiquement, supprimez simplement la référence du sous-module, ce qui est beaucoup moins gênant que la réécriture de votre historique pour filtrer 400 Mo de données.