Garder automatiquement un dépôt secondaire synchronisé avec un dépôt principal?
Nous avons une configuration à deux niveaux.
Nous avons un référentiel principal (appelé "primaire" ci-dessous).
Et un référentiel secondaire (appelé "secondaire" ci-dessous) qui a été créé comme suit:
$ git clone --bare --shared $REPO_A/primary secondary.git
Les personnes travaillant sur le référentiel secondaire voient les branches qui provenaient du référentiel principal en lecture seule mais basent leurs propres branches sur ces branches.
Nous voulons synchroniser le référentiel secondaire avec le référentiel principal une fois par jour.
C'est à dire. nous voulons que les validations et les nouvelles branches qui ont été poussées vers le primaire deviennent visibles pour les personnes travaillant hors du référentiel secondaire (la prochaine fois qu'elles feront un pull).
Nous ne voulons pas que cela soit symétrique, c'est-à-dire que l'activité contre le référentiel secondaire ne deviendra pas visible pour ceux qui travaillent hors du référentiel principal.
Idéalement, je voudrais exécuter un travail cron qui s'exécute sur la machine avec le référentiel secondaire nu qui récupère en quelque sorte les nouvelles données du primaire et les inclut automatiquement dans le secondaire.
J'espérais qu'il pourrait y avoir un moyen simple de le faire (et j'espère que quelqu'un ici me le dira).
Si je devais écrire un script pour le faire, cela ferait:
Créez un nouveau clone du secondaire.
$ git clone $REPO_B/secondary $ cd secondary
Obtenez toutes ses succursales.
$ git branch -r | sed 's?.*Origin/??'
Obtenez toutes les succursales dans le référentiel principal.
$ git ls-remote --heads $REPO_A/primary | sed 's?.*refs/heads/??'
Pour chaque branche primaire pour laquelle je n'ai pas encore de branche secondaire correspondante:
$ git fetch $REPO_A/primary $BRANCHNAME:$BRANCHNAME $ git Push Origin $BRANCHNAME:refs/heads/$BRANCHNAME
Pour chaque branche primaire pour laquelle j'ai déjà une branche secondaire correspondante:
$ git checkout -b $BRANCHNAME --track Origin/$BRANCHNAME $ git pull $REPO_A/primary $BRANCHNAME $ git Push
Comme je suis nouveau sur git, je ne serais pas surpris si je n'avais pas pris en compte certains problèmes fondamentaux?
Et comme je l'ai dit, j'espère qu'il y a une façon plus simple de le faire, c'est-à-dire que quelqu'un dit "oh, ne fais pas tout ça, fais juste ...".
Oh, ne fais pas tout ça, fais juste:
git --bare fetch
;)
(Voir ceci ancien fil par exemple )
Si vous avez ajouté les origines distantes pertinentes à votre référentiel nu, vous pouvez récupérer tour à tour chacune de ces origines.
Vous pouvez simplement faire un git clone --bare --mirror
et faire périodiquement un git fetch
pour y arriver.
Je le fais en temps réel en utilisant un outil appelé gitmirror J'ai écrit dans node.js que je tourne sur une machine à la maison pour recevoir des webhooks de github ainsi que des hooks ad hoc pour synchroniser les commits.
Pour un exemple non github, j'ai un dépôt qui est utilisé pour une sauvegarde couchdb qui a un commit environ une fois par heure. Le travail cron se résume essentiellement à ceci:
# do some backup stuff
git commit -qam "Backup `date`" >> dump.log 2>&1
De là, j'ai un hook post-commit (.git/hooks/post-commit
) qui ressemble à ceci:
#!/bin/sh
curl -sS http://my.home.machine/gitmirror/bak/repo-name.git
Vous pouvez accomplir la même chose en poussant du côté récepteur. Cela a l'avantage de tirer et d'oublier la charge utile dans le cas normal.
Je voudrais voir cela comme un outil Git standard. Mais ces cas sont rares. Le plus souvent, cela signifie qu'il y a des limites dans votre environnement.
J'ai créé quelques outils pour ce problème et l'un d'eux couvre mes besoins.
Mais je dois avertir que ces outils nécessitent des connaissances et de l'expérience.
Ma documentation est médiocre car elle ne correspond qu'à mes besoins et je n'ai pas de communauté pour répondre correctement. Désolé. Ne perdez pas votre temps, car vous devez vraiment y investir votre temps.
gitSync - juste installer (c'est difficile) et utiliser.
( convention-over-git - vous pouvez saisir des idées d'ici et écrire vos propres scripts ou un outil .
Mais néanmoins, gytSync résout vraiment le problème pour moi.
J'ai créé gitSync en 2017. Nous l'utilisons tout le temps et tout est parfait.
Oui, j'ai corrigé quelques bugs))
gitSync synchronise les branches git entre deux référentiels git distants via HTTP.
Les branches synchronisées doivent suivre une convention de dénomination.
La convention de nommage est décrite dans mon blog Convention over Git . (J'ai inventé la convention avant de créer gitSync.)
Vos équipes peuvent même travailler sur la même branche Git synchronisée. Aucun problème.
C'est parce que gitSync a automatisé la résolution des conflits.
Voir les détails dans Résolution des conflits Git car vous devrez peut-être réengager vos modifications en cas de conflits.
En effet, je connecte différentes notifications par e-mail à gitSync car il exporte différents états d'exécution dans des fichiers.
En raison de la résolution automatisée des conflits, n'importe qui peut effectuer la fusion Git dans les deux référentiels distants sur n'importe quelle branche synchronisée et elle sera synchronisée.
Cela signifie que si une seule de vos équipes est capable de fusionner Git ou de résoudre des conflits, elle le fera avec succès pour les deux référentiels de n'importe quel référentiel.
gitSync a même des protections contre l'effacement occasionnel du référentiel Git.
l'outil gitSync résiste aux problèmes de réseau, d'E/S et de système d'exploitation. En vertu de Git lui-même et de quelques-unes de mes idées implémentées dans gitSync. Je l'ai mis dans une architecture avant même d'avoir créé gitSync. Et cela a été prouvé par une utilisation continue.
J'exécute gitSymc par différents crons, par PowerShell Scheduled Jobs, par Automation Serves (Jenkins, etc.) et manuellement.