Au début: c'est (espérons-le-dire) aucun duplicata de Ce < / a> ou Ce .
L'état actuel: J'ai commis un fichier avec des informations d'identification pour une base de données interne à mon référentiel Git. C'était bien, comme je l'utilisais seulement seul. Ensuite, mon groupe a commencé à cloner, pousser et retirer dans ce projet. Nous avons maintenant plusieurs référentiels Git (un centre et certains développeurs).
Le problème: Nous voulons maintenant donner accès au public au code source et au référentiel GIT ou au moins laissez Git gérer les détails des autres contribuant au code.
a) Supprimez le fichier avec les informations d'identification du centre ou de tous les référentiels ou
B) Configurez un nouveau référentiel git comme type d'interface sur le monde extérieur?
Si vous choisissez (b), comment pouvons-nous facilement communiquer les modifications vers le référentiel principal?
En raison de la distribution déjà répandue, nous aimerions vraiment ne pas faire un git rebase ou un filtre-filtre git sur chaque référentiel actuel.
4 Réponses :
Désolé, mais vous êtes coincé avec l'exécution en raison de Conception, il n'y a aucun moyen de forcer les clones existants à supprimer le fichier de leurs histoires respectives. p> Vous pouvez assainir une seule branche et en faire la base du développement futur: P> Git filtre-branche code> si vous souhaitez supprimer les informations d'identification du référentiel principal. Voir Suppression de données sensibles , écrite par les personnes à Github. $ git push new-central master
Il n'y a aucun moyen que vous puissiez faire a) sans utiliser Rebase ou filtre-branche. Mais je dirais que c'est probablement préférable de le faire de cette façon, que de devoir avoir du mal à cacher l'histoire pour toujours. Je suppose que b) pourrait être fait en divisant l'histoire après un engagement qui supprime les informations d'identification. Le résultat serait à peu près deux histoires, placée dans deux repos différents; un avant le nettoyage et celui qui "redémarre" juste après. L'histoire de ces deux repos pourrait être connectée via points de greffe dans les repos de ceux qui ont besoin d'atteindre la vieille histoire.
De toute façon, vous allez devoir traiter de toute une charge de sh * t, et je recommanderais d'aller pour a) et une branche filtrante même si cela fait beaucoup de travail.
Désolé de s'accepter votre réponse, mais le lien vers GitHub dans la réponse de Gbacon valait son poids en or.
Changer simplement le mot de passe de votre base de données interne et tout autre service ayant le même mot de passe. (et même pour tout autre mot de passe existant quelque part dans votre histoire).
Curieux, que j'ai oublié de uploter cette réponse. Dans notre cas particulier, cela n'était pas applicable, mais dans le cas général, c'est la voie à suivre pour un paysage de dépôt répandu et je l'ai même fait une fois, quand j'ai publié un projet de mien pour animaux de compagnie. (On dirait que je devrais vérifier à l'avenir, ce que je vous engageons ...)
Alors, nous sommes à travers et j'aimerais partager la façon dont nous l'avons fait enfin.
Nous étions dans la position chanceuse que personne n'avait une branche personnalisée à un moment donné. Donc, ce que nous avons essentiellement fait, c'est que tous ont poussé une dernière fois leurs affaires au référentiel central.
Ensuite, nous avons utilisé Enfin (et qui fonctionnait uniquement parce que personne n'avait une succursale locale mentionnée), nous avons supprimé nos référentiels locaux et clonés de nouveaux de la centrale maintenant propre.
Mettez-le en un mot: de cette façon, c'était une procédure assez rapide et sans douleur. Pas élégant, mais cela a fonctionné. filtre-branche comme décrit par l'équipage GitHub dessus. Nous avons alors eu un référentiel central clair.