Comment organiser plusieurs référentiels git, afin qu'ils soient tous sauvegardés ensemble ?

StackOverflow https://stackoverflow.com/questions/36862

  •  09-06-2019
  •  | 
  •  

Question

Avec SVN, j'avais un seul grand référentiel que je gardais sur un serveur et que je vérifiais sur quelques machines.C'était un très bon système de sauvegarde et me permettait de travailler facilement sur n'importe quelle machine.Je pouvais extraire un projet spécifique, le valider et mettre à jour le projet « maître », ou je pouvais extraire le tout.

Maintenant, j'ai un tas de dépôts git, pour divers projets, dont plusieurs sont sur github.J'ai aussi le dépôt SVN que j'ai mentionné, importé via la commande git-svn.

Fondamentalement, j'aime avoir tout mon code (pas seulement des projets, mais des extraits et des scripts aléatoires, certaines choses comme mon CV, les articles que j'ai écrits, les sites Web que j'ai créés, etc.) dans un grand référentiel que je peux facilement cloner à distance. machines ou clés USB/disques durs comme sauvegarde.

Le problème est que, puisqu'il s'agit d'un référentiel privé et que git ne permet pas l'extraction d'un dossier spécifique (que je pourrais pousser vers github en tant que projet distinct, mais que les modifications apparaissent à la fois dans le dépôt principal et dans le sous- pensions)

je pourrait utilisez le système de sous-modules git, mais il n'agit pas non plus comme je le souhaite (les sous-modules sont des pointeurs vers d'autres référentiels et ne contiennent pas vraiment le code réel, donc c'est inutile pour la sauvegarde)

Actuellement, j'ai un dossier de git-repos (par exemple, ~/code_projects/proj1/.git/ ~/code_projects/proj2/.git/), et après avoir modifié proj1, je le fais git push github, puis je copie les fichiers dans ~/Documents/code/python/projects/proj1/ et effectue un seul commit (au lieu des nombreux dans les dépôts individuels).Alors fais git push backupdrive1, git push mymemorystick etc.

Alors, la question :Comment gérer votre code personnel et vos projets avec les référentiels git et les garder synchronisés et sauvegardés ?

Était-ce utile?

La solution

Je voudrais fortement conseiller de mettre des données non liées dans un référentiel GIT donné.Les frais généraux de la création de nouveaux référentiels sont assez faibles, et c'est un fonctionnalité Cela permet de garder différentes lignées complètement séparées.

Combattre cette idée signifie se retrouver avec une histoire inutilement enchevêtrée, ce qui rend l'administration plus difficile et plus importante - les outils "archéologie" moins utiles en raison de la dilution qui en résulte.De plus, comme vous l'avez mentionné, Git suppose que «l'unité de clonage» est le référentiel et doit pratiquement le faire en raison de sa nature distribuée.

Une solution consiste à conserver chaque projet/package/etc.comme le sien nuRéférentiel (c'est-à-dire sans arbre de travail) sous une hiérarchie bénie, comme:

/repos/a.git
/repos/b.git
/repos/c.git

Une fois que quelques conventions ont été établies, il devient trivial d'appliquer les opérations administratives (sauvegarde, emballage, publication Web) à la hiérarchie complète, qui sert un rôle non entièrement différent des référentiels SVN "monolithiques".Travailler avec ces référentiels devient également quelque peu similaire aux workflows SVN, avec l'ajoutpeut utilisez des commits et des branches locaux :

svn checkout   --> git clone
svn update     --> git pull
svn commit     --> git push

Vous pouvez avoir plusieurs télécommandes dans chaque clone de travail, pour la facilité de synchronisation entre les multiples parties:

$ cd ~/dev
$ git clone /repos/foo.git       # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...

Vous pouvez ensuite récupérer / tirer de chacune des "sources", travailler et vous engager localement, puis pousser ("sauvegarde") à chacun de ces télécommandes lorsque vous êtes prêt avec quelque chose comme (notez comment cela pousse le même Commits et histoire à chacun des télécommandes!):

$ for remote in origin github memorystick; do git push $remote; done

Le moyen le plus simple de transformer un référentiel de travail existant ~/dev/foodans un dépôt aussi simple est probablement :

$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git

ce qui équivaut en grande partie à un svn import- mais ne jette pas l'histoire "locale" existante.

Note: sous-modules sont un mécanisme pour inclure les en rapportLes lignées, donc je ne les considérerais pas en effet comme un outil approprié pour le problème que vous essayez de résoudre.

Autres conseils

Je veux ajouter à La réponse de Damien où il recommande :

$ for remote in origin github memorystick; do git push $remote; done

Vous pouvez configurer une télécommande spéciale à envoyer à toutes les télécommandes réelles individuelles avec 1 seule commande ;Je l'ai trouvé chez http://marc.info/?l=git&m=116231242118202&w=2:

Donc, pour "Git Push" (où il est logique de pousser les mêmes branches plusieurs fois), vous pouvez réellement faire ce que je fais:

  • .git/config contient :

    [remote "all"]
url = master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
url = login.osdl.org:linux-2.6.git

  • et maintenant git push all master poussera la branche "master" vers les deux
    de ces référentiels distants.

Vous pouvez également vous épargner de taper deux fois les URL en utilisant la construction :

[url "<actual url base>"]
    insteadOf = <other url base>

Je suis également curieux de connaître les façons suggérées de gérer cela et je décrirai la configuration actuelle que j'utilise (avec SVN).J'ai essentiellement créé un référentiel qui contient une hiérarchie de mini-systèmes de fichiers comprenant ses propres répertoires bin et lib.Il y a un script à la racine de cette arborescence qui configurera votre environnement pour ajouter ces bin, lib, etc...d'autres répertoires vers les variables d'environnement appropriées.Le répertoire racine ressemble donc essentiellement à :

./bin/            # prepended to $PATH
./lib/            # prepended to $LD_LIBRARY_PATH
./lib/python/     # prepended to $PYTHONPATH
./setup_env.bash  # sets up the environment

Maintenant, dans /bin et /lib se trouvent les multiples projets et leurs bibliothèques correspondantes.Je sais que ce n'est pas un projet standard, mais il est très facile pour quelqu'un d'autre dans mon groupe de récupérer le dépôt, d'exécuter le script 'setup_env.bash' et de disposer des versions les plus récentes de tous les projets localement dans leur vérifier.Ils n'ont pas à se soucier de l'installation/mise à jour de /usr/bin ou /usr/lib et il est simple d'avoir plusieurs extractions et un environnement très localisé par extraction.Quelqu'un peut également simplement configurer l'intégralité du référentiel sans se soucier de la désinstallation des programmes.

Cela fonctionne bien pour nous et je ne suis pas sûr que nous allons le changer.Le problème est qu’il existe de nombreux projets dans ce seul grand référentiel.Existe-t-il un moyen standard git/Hg/bzr de créer un environnement comme celui-ci et de répartir les projets dans leurs propres référentiels ?

,Je n'ai pas encore essayé d'imbriquer les référentiels git car je n'ai pas rencontré de situation où j'en aurais besoin.Comme je l'ai lu sur le chaîne #git git semble être confus en imbriquant les référentiels, c'est-à-direvous essayez de git-init dans un référentiel git.La seule façon de gérer une structure git imbriquée est d'utiliser git-submodule ou Android repo utilitaire.

Quant à cette responsabilité de sauvegarde que vous décrivez, je dis déléguer il...Pour moi, je place généralement le référentiel « origine » de chaque projet sur un lecteur réseau au travail qui est régulièrement sauvegardé par les techniciens informatiques par la stratégie de sauvegarde de leur choix.C'est simple et je n'ai pas à m'en soucier.;)

Qu'en est-il de l'utilisation M. pour gérer vos multiples dépôts Git à la fois :

La commande MR (1) peut vérifier, mettre à jour ou effectuer d'autres actions sur un ensemble de référentiels comme s'il s'agissait d'un répondant combiné.Il prend en charge toute combinaison de subversion, GIT, CVS, Mercurial, BZR, DARCS, CVS, VCSH, Fossil and Veracity Repositaires, et le support pour d'autres systèmes de contrôle de révision peut facilement être ajouté.[...]

Il est extrêmement configurable via de simples scripts shell.Quelques exemples de choses qu'il peut faire comprend:

[...]

  • Lors de la mise à jour d'un référentiel git, extrayez deux amonts différents et fusionnez les deux ensemble.
  • Exécutez plusieurs mises à jour du référentiel en parallèle, accélérant considérablement le processus de mise à jour.
  • Mémorisez les actions qui ont échoué en raison de la mise hors ligne d'un ordinateur portable, afin de pouvoir les réessayer lorsqu'il revient en ligne.

Il existe une autre méthode pour avoir des dépôts git imbriqués, mais cela ne résout pas le problème que vous recherchez.Pourtant, pour ceux qui recherchent la solution, j'étais :

Dans le dépôt git de niveau supérieur, cachez simplement le dossier dans .gitignore contenant le dépôt git imbriqué.Cela facilite la création de deux dépôts git distincts (mais imbriqués !).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top