Garder les référentiels git sur différents hôtes synchronisés

Je pense à démarrer un petit projet et je veux faire sa gestion des versions avec git.

Bitbucket semble être une bonne option pour moi avec leur forfait gratuit. Je souhaite l'utiliser comme principal outil de travail avec git car ils disposent d'outils utiles, tels qu'une interface Web, un client Mac OS, etc. Toutefois, afin de bénéficier d'une protection accrue contre les dommages accidentels pouvant être causés par l'utilisation d'un service tiers, je souhaite également installer git sur mon NAS en tant que seconde copie de sauvegarde du référentiel.

Ma question est la suivante: est-il possible de créer un référentiel sur deux hôtes différents, puis de les synchroniser? Par exemple, supposons qu'une fois par semaine je mette à jour le référentiel sur mon NAS pour qu'il corresponde à celui de Bitbucket. Ensuite, si quelque chose se produit avec Bitbucket, je conserverai le référentiel complet avec l'historique complet du développement sur mon stockage NAS local.

Et est-il possible d'importer un référentiel existant avec l'historique complet vers un autre service git?

Je pense que le reflet est ce dont j'ai besoin. Cet article semble décrire exactement ce dont j'ai besoin. Et celui- ci aussi.

Je crois qu'il en fera une copie complète avec l'historique complet et que même les nouvelles versions seront automatiquement validées dans les référentiels des deux hôtes.

Ai-je raison?

git

— BartoNaz
source

J'utilise xpdev Je me demande dans votre situation de 2 système ce que le bennefit serait de rusing git dans votre cas. juste pour être sûr de chaque construction finale, je fais une sauvegarde usb. Mais le gestion de version est gérée par xpdev, donc ce n’est pas une exigence réelle. BTW si vous possédez un NASS Raid indéréglable ou alors vous pourriez envisager d'exécuter vos propres systèmes de gestion de versions, il y a aussi des freeones aussi

— user613326

Mais je veux avoir la version complète disponible à 2 endroits. Si le tiers hébergement meurt ou si la société qui l'exécute disparaît, je souhaite avoir exactement la même expérience avec tous les antécédents de gestion de versions ...

— BartoNaz

Cela signifie que je vais avoir Bitbucket pour le confort et git sur NAS pour 99,9% de sécurité.

— BartoNaz

Quant à xp-dev, il est peu probable qu'une telle société meure, elle peut modifier les plans d'hébergement de code, les prix, etc. ou fusionner avec une autre société. Mais c'est une laitière d'argent pour eux. Et ils vont également sauvegarder les données précieuses. C'est leur affaire de rester en place. Je l'utilise avec 3 développeurs, et notre code existe sur 5 machines différentes, où il y a toujours une copie source locale qui est synchronisée sur xp dev. XP dev est gratuit si vous n'avez que quelques projets.

— user613326

Bien sûr, c'est peu probable. Mais toujours, vous ne pouvez jamais être sûr à 100% ...

— BartoNaz

Réponses:

Oui, c’est exactement la beauté de DVCS comme Git. Vous pouvez utiliser un nombre quelconque de dépôts avec le même état que celui de bitbucket ou de github.

Même votre copie locale (le référentiel sur votre ordinateur) est généralement un clone complet du référentiel distant.

La seule chose que vous ayez à faire pour garder plusieurs pensions synchronisées en synchronisation consiste à en extraire une (généralement appelée origine ou en amont) et à la placer sur les copies de sauvegarde.

— Wilbert
source

Malheureusement, tout n'est pas aussi brillant. Voir la mise en garde de KDE au bord de la catastrophe . En d'autres termes, assurez-vous que la sauvegarde ne supprime pas les éléments (branches, référentiels, etc.) supprimés sur le serveur sauvegardé.

— Jan Hudec le

Je ne suis toujours pas sûr de l'avoir bien comprise. Autant que je sache, pousser et tirer fonctionne avec une certaine version. Mais disons que j'ai une version récente du code sur ma machine de travail. J'ai le référentiel git sur l'hôte distant (Bitbucket, Github ou toute autre chose), qui possède un historique complet du développement du code jusqu'à la version la plus récente que j'ai sur la machine en fonctionnement (si elle a été validée). Et j'ai un référentiel sur le NAS qui est vide. Puis-je importer l'historique complet du code de l'hôte distant sur mon NAS afin que je dispose de deux référentiels identiques à deux endroits et comment?

— BartoNaz

Clonez le référentiel distant, puis extrayez-le toutes les mises à jour (toutes les branches) à intervalles réguliers. Un clone git contient l'historique, ce n'est pas comme un svn checkout qui n'a que la dernière version.

— Wilbert

Voici une solution testée pour le problème: Référentiels Git distants Automatic Sync 2

Un script simple pour la synchronisation de 2 référentiels Git distants

J'ai cherché sur le Web un script simple à synchroniser. 2 dépôts distants mais je ne pouvais pas trouver un tel script, même si beaucoup semblent le chercher! J'ai donc créé 2 référentiels de test simples et commencé à tester et à créer ce script.

Qu'est-ce qu'un tel script devrait faire?

En général, les étapes à suivre sont simples: 1. Clonez le premier référentiel. 1. Ajoutez le deuxième en tant que référentiel distant supplémentaire. 1. Récupérez tout ce qu'il y a dans le deuxième référentiel. dépôts distants.

La question qui reste est la suivante: quels sont les bons commutateurs pour toutes les commandes git ci-dessus?

Alors la voici ...

2repos-sync.sh script gisp

# Clear the folder first - please use this carefully
rm -rf $REPO_NAME  
# clone the reposotory
git clone --bare $ORIGIN_URL

# add a remote repository
cd $REPO_NAME
git remote add --mirror=fetch repo1 $REPO1_URL

# update the local copy from the first repository
git fetch origin --tags

# update the local copy with the second repository
git fetch repo1 --tags

# sync back the 2 repositories
git push origin --all
git push origin --tags
git push repo1 --all
git push repo1 --tags

NOTE - Ce script ne résout pas les problèmes de conflits entre le contenu du référentiel!

— Yorammi
source

Vous voudrez peut-être mentionner dans votre réponse que la première chose à faire est de supprimer un répertoire local existant avec $ REPO_NAME. Cela semble important et pourrait éviter la perte de données aux personnes qui copient simplement votre solution.

— Wilbert

Pour ce faire, LibGit2 est utile pour ce genre de chose.

— RubberDuck

J'utilise un GitLab privé pour stocker tous mes référentiels, de sorte que je n'ai qu'une origine sur laquelle je peux pousser et tirer pendant que je développe quotidiennement.

Mais, pour les projets open source, GitHub est une communauté beaucoup plus dynamique. Par conséquent, si je souhaite accepter les contributions de la communauté à mes projets, j'utilise le système de hook Web de GitLab Web pour envoyer une requête ping à un serveur que je lance, puis met à jour mon dépôt public sur GitHub.

Cela me permet de traiter GitHub comme une autre télécommande que je peux extraire lorsque quelqu'un contribue - puis je fusionne - aucun-ff localement, et il y a un flux vers la façon dont tous mes référentiels principal et public distribuent les modifications.

— diffalot
source