git mise en miroir de GitHub et filtrage de fichiers privés

Question

Actuellement en cours de traitement d'un projet. Nous voulons open-source nos commits au jour le jour avec des informations complètes (auteur, etc ...) tout en filtrant certains dossiers privés spécifiques. Supposons que je valide A/file1 et B/file2 dans le maître de branche, je voudrais le mettre en miroir sur GitHub avec le dossier B filtré (ce commit aurait uniquement A/file1).

Une façon je pensais le faire est un crochet de mise à jour à distance qui:

• Liste toute nouvelle engage ajoutée par newref (disons lastfoundcommit..newref)
• Modifier les commits un par un (de lastfoundcommit à newref) pour supprimer les fichiers indésirables
• Dans le processus, il pourrait créer une branche maîtresse filtrée locale (si elle aide à avoir localement)
• Pousser cette branche dépôt public
• garder une certaine façon une mise en correspondance de commettre ID entre commits publics et privés, pour calculer facilement « lastfoundcommit » sur la prochaine poussée

Idéalement, il pourrait aller à la fois chemin (elle serait bien si nous pouvions aussi réimporter branches GitHub et tirer des requêtes et les faire "rebaser" sur notre dépôt privé, soit automatiquement ou avec un processus simple - probablement pas si dur que c'est probablement juste un rebase).

Ceci est quelque peu similaire à ce que git-subtree peut faire, sauf qu'il ne s'agit pas d'extraire un sous-répertoire mais de filtrer divers fichiers à la place.

Est-ce que cela semble faisable? Ou toute autre suggestion? (peut-être basé sur git filter-branch? ou tout autre outil/script existant qui pourrait m'aider?)

Note: sous-module n'est pas une option viable, car ils pourraient être rares et il serait trop encombrer. En outre, la liste des fichiers "privés" peut s'étendre/changer avec le temps.

Answer 1

Votre plan est correct, sauf qu'il doit utiliser git filter-branch pour réécrire les validations. La commande filter-branch est conçue à des fins comme celles-ci et vous donne le pouvoir maximal de réécrire les commits de la manière que vous désirez.

Il serait assez facile d'avoir les scripts que vous fournissez à filter-branch enregistrer le mappage de validation de l'ancien à nouveau. Cela dit, même si vous dites que les sous-modules ne sont pas une option viable, à mon avis, l'utilisation d'un dossier «privé» au plus haut niveau qui est en fait un dépôt git hébergé séparément est une meilleure idée que l'histoire de réécrire. re proposer. C'est moins sujette aux erreurs, plus facile à implémenter et plus facile à comprendre.

Answer 2

Je suis dans une situation similaire:

Ne pas utiliser la branche de filtre git

Utilisez BFG repo cleaner à la place. C'est BEAUCOUP plus rapide et plus facile à utiliser.

Vous devez élaguer régulièrement tous les validations de votre dépôt pour ne pas mentionner vos dossiers/fichiers privés.

Diviser les dépôts

repo Demandez plein ET OSS un. Laissez vos scripts transférer des fichiers de l'un vers l'autre et effectuer des tests spéciaux sur OSS afin de ne PAS TROUVER ce que vous n'êtes pas censé faire.

Les deux référentiels doivent se trouver dans votre réseau, de préférence sur la même machine (sécurité). Seule la branche autorisée, vérifiée et nettoyée du référentiel OSS quitte la machine (pousser vers GitHub ou n'importe où).

Utilisez

sous-modules

Est-ce un POC avec/sous-modules pour voir si sous-arborescences ils ne fonctionneront pas mieux que les scripts. Vous gaspillerez 2 heures supplémentaires et vous saurez à coup sûr. Je pense qu'ils pourraient être des options viables puisque les gars ont des dossiers privés ...

Utiliser projet et .git ignore/info/ exclus

Vous pouvez utiliser .git/info/exclude pour exclure des fichiers et dossiers privés dans repo OSS, que Ainsi, même l'information sur eux étant délibérément évitée de l'attention de Git ne fuit pas.

Sur votre dépôt habituel, vous pouvez ajouter ces fichiers à .gitignore, sur une branche, qui sert de filtre initial et qui est ensuite utilisé pour alimenter le repo OSS.