Sauvegardez efficacement de nombreuses versions d'un dépôt git avec l'espacement des noms de branche

Question

Au travail, nous utilisons Perforce pour le contrôle de version.Il y a des problèmes avec ça :1) avec ce modèle centralisé, nous ne pouvons pas enregistrer les modifications tant qu'elles ne sont pas prêtes 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 la vue client du dépôt, notre travail est donc dangereux jusqu'à ce que nous puissions l'enregistrer.3) Nous avons des problèmes pour partager notre code avec chacun, à moins que nous suppliions de mettre en place une branche d'intégration.J'essaie de mettre en place un workflow git facultatif pour les développeurs qui souhaitent utiliser git pour résoudre ces problèmes.

Le plan est d'utiliser git-p4 pour s'interfacer avec le serveur Perforce et créer un dépôt git privé.Cela prend en charge 1).Je prévois d'utiliser le workflow du gestionnaire d'intégration décrit dans Git Pro (http://progit.org/book/ch5-1.html) pour que nos développeurs publient des dépôts publics, en s'occupant de 3).

Enfin, je veux un endroit où les développeurs peuvent pousser leurs modifications afin qu'elles soient intégrées aux sauvegardes nocturnes/sauvegardes hors site.La raison pour laquelle nous ne sauvegardons pas nos vues client maintenant est que faire des sauvegardes d'archives nocturnes de la vue client de chacun est inefficace en termes d'espace.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 chacun.Nous voulons seulement préserver le les changements uniques qu'ils apportent seulement.

Je pensais avoir un seul dépôt git, appelez-le omni-backup, vers lequel tout le monde peut pousser toutes ses branches (et n'hésitez pas à suggérer des alternatives).Cela utiliserait le hachage sha-1 économe en espace de git et garantirait que seules les 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 une efficacité spatiale.

Le problème, c’est lorsque deux personnes ayant des succursales complètement différentes choisissent le même nom pour leur succursale.PAR EXEMPLE.Bob a un feature succursale et Jane a un feature branche, mais ils sont destinés à des fonctionnalités différentes.Si Bob opte pour la sauvegarde omni, Jane ne pourra pas le faire, car il ne s'agirait pas d'une fusion rapide.

Maintenant, ce que j'aimerais idéalement, c'est que lorsque Bob pousse sa branche de fonctionnalités, la branche soit renommée en bob-feature sur le omni-backup télécommande.Et quand il retire une fonctionnalité de omni-backup, il revient bob-feature.

Cela ne semble pas très facile à réaliser avec git.Il semble que je puisse utiliser les crochets poussoirs documentés dans http://www.kernel.org/pub/software/scm/git/docs/git-receive-pack.html hook post-réception pour réécrire le nom de la référence immédiatement après son écriture, puis quelque chose pourrait être fait pour inverser le processus sur le chemin du retour, mais cela semble fragile.Quelqu'un a-t-il une meilleure idée ?

---

modifier:Pour VCIC (parce que le code suce les commentaires), votre chemin semble prometteur, Vonc, mais je ne vois pas comment le fait qu'il s'agissait d'un fetch battra les problèmes d'espacement de noms.Proposez-vous un travail cron qui sait comment renommer la branche ?

comme (vraiment 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 que le développeur pousse vers omni-backup dépôt?

À des fins de sauvegarde, je préfère enregistrer le référentiel des différents développeurs comme distant et faire un git fetch tous les soirs (du omni-backup serveur) sur tous les dépôts distants.
De cette façon, aucune collusion sur les noms de succursales n’est possible.Et un processus plus automatisé (le développeur n'a pas besoin de pousser explicitement quoi que ce soit sur un dépôt avec lequel il ne travaille pas directement, mais n'envisagerait que la sauvegarde)

Ensuite, je produirais un joli petit git archive hors de omni-backup et rangez-le.

Answer 2

Si vous parvenez à 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-backup est la référence distante du référentiel, alors la branche de fonctionnalité de bob poussera vers bob-feature sur omni-backup.Mais si confier cela aux développeurs n'est pas souhaitable, changer la direction du flux et demander à la sauvegarde omni d'extraire les référentiels des développeurs, comme le suggère VonC, est la meilleure solution.