Sauvegarde efficace de nombreuses versions d'un repo git avec un espace de noms de branche

Question

Au travail, nous utilisons Perforce pour le contrôle de version. Il y a des problèmes avec ceci: 1) avec ce modèle centralisé, nous ne pouvons pas vérifier les changements jusqu'à ce qu'ils soient prêts pour la régression. Cela signifie que nous n'avons aucun contrôle de révision pendant le processus de développement. 2) Nous ne sauvegardons pas notre vue client du dépôt, donc notre travail est dangereux jusqu'à ce que nous puissions le vérifier. 3) Nous avons des problèmes pour partager notre code avec chacun sauf si nous demandons une branche d'intégration. J'essaie de mettre en place un workflow git optionnel pour les développeurs qui veulent utiliser git pour résoudre ces problèmes.

Il est prévu d'utiliser git-p4 pour s'interfacer avec le serveur perforce et créer un repo git privé. Cela prend soin de 1). Je prévois d'utiliser le workflow intégration-manager décrit dans Git Pro (http://progit.org/book/ch5-1.html) pour que nos développeurs publient des repos publics, en prenant soin de 3).

Enfin, je veux un endroit où les développeurs peuvent pousser leurs changements afin qu'ils tiré dans les sauvegardes nocturnes/sauvegardes hors site. La raison pour laquelle nous ne sauvegardons pas les vues de nos clients maintenant est que les sauvegardes archivistiques nocturnes de la vue client de tout le monde sont inefficaces. Nous avons beaucoup de développeurs et ils produisent beaucoup de code. Nous ne pouvons pas sauvegarder de manière redondante la vue client de tout le monde. Nous voulons seulement préserver les changements uniques qu'ils font seulement.

Ma pensée était d'avoir un seul repit git, appelez-le omni-backup, que tout le monde peut pousser toutes leurs branches (et n'hésitez pas à suggérer des alternatives). Ceci utiliserait le hachage sha-1 git efficace dans l'espace et garantirait que seules des versions uniques de chaque fichier sont sauvegardées. L'astuce est que tous les référentiels de sauvegarde doivent faire partie du même référentiel pour obtenir l'efficacité de l'espace.

Le problème est lorsque deux personnes avec des branches complètement différentes choisissent le même nom pour leur branche. PAR EXEMPLE. Bob a une branche feature et Jane a une branche feature, mais ils ont des caractéristiques différentes. Si Bob pousse l'omni-sauvegarde, Jane ne pourra pas le faire, car il ne s'agira pas d'une fusion rapide.

Maintenant, ce que je voudrais idéalement arriver, c'est que lorsque Bob pousse sa branche de fonctionnalité, la branche sera renommée bob-feature sur la télécommande omni-backup. Et quand il tire la caractéristique de omni-backup, il revient bob-feature.

Cela ne semble pas très facile à accomplir dans git. Il semble que je peux utiliser des crochets documentés dans http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html post-recevoir un crochet pour réécrire le nom de l'arbitre immédiatement après l'avoir écrit, puis quelque chose pourrait être fait pour inverser le processus sur le chemin du retour, mais il se sent fragile. Quelqu'un a une meilleure idée?

---

edit: pour VonC (parce que le code suce dans les commentaires) Votre semble prometteur, VonC, mais je ne vois pas comment le fait que c'est un fetch battre les problèmes de l'espace de nommage. Suggérez-vous un cronjob qui sait comment renommer la branche?

comme (très sale):

foreach my $user (@users) { 
    my @branches = split(/s/,cat `$LDAPSERVER/$USER/$REPO/.git/refs/heads`); 
    foreach my $branch (@branches) { 
     system "git fetch $LDAPSERVER/$USER/$REPO/$BRANCH:+$USER$BRANCH" 
    } 
} 

Answer 1

Pourquoi auriez-vous besoin pour les développeurs de pousser à omni-backup repo?Pour des raisons de sauvegarde, je préfèrerais enregistrer le référentiel du développeur différent comme distant, et faire un git fetch chaque nuit (à partir du serveur omni-backup) sur tous les dépôts distants.
Ainsi, aucune association de nom de branche n'est possible. Et un processus plus automatisé (le développeur n'a pas explicitement pousser quoi que ce soit sur une prise en pension, il/elle ne travaille pas directement avec, mais il ne prendra en considération pour la sauvegarde)

Je produirait un joli petit git archive sur omni-backup et rangez-le.

Answer 2

Si vous pouvez amener les développeurs à suivre certaines directives, git push peut le faire correctement.

Si vous exécutez cette commande:

git push omni-backup feature:bob-feature 

où omni-sauvegarde est l'arbitre à distance pour le dépôt, puis la branche fonction de bob va pousser à bob-fonctionnalité sur omni-sauvegarde. Mais si confier cela aux développeurs est indésirable, changer la direction du flux et avoir omni-backup tirer les référentiels des développeurs, comme VonC suggère, est la meilleure solution