Wie organisieren Sie mehrere Git-Repositorys, sodass alle gemeinsam gesichert werden?

Question

Mit SVN hatte ich ein einziges großes Repository, das ich auf einem Server aufbewahrte und auf einigen Computern auscheckte.Dies war ein ziemlich gutes Backup-System, mit dem ich problemlos auf allen Maschinen arbeiten konnte.Ich könnte ein bestimmtes Projekt auschecken, ein Commit durchführen und dadurch das „Master“-Projekt aktualisieren, oder ich könnte das gesamte Projekt auschecken.

Jetzt habe ich eine Reihe von Git-Repositories für verschiedene Projekte, von denen sich einige auf Github befinden.Ich habe auch das SVN-Repository, das ich erwähnt habe, importiert über den Befehl git-svn.

Grundsätzlich mag ich es, meinen gesamten Code (nicht nur Projekte, sondern auch zufällige Snippets und Skripte, einige Dinge wie meinen Lebenslauf, Artikel, die ich geschrieben habe, Websites, die ich erstellt habe usw.) in einem großen Repository zu haben, das ich problemlos auf Remote klonen kann Maschinen oder Speichersticks/Festplatten als Backup.

Das Problem besteht darin, dass es sich um ein privates Repository handelt und Git das Auschecken aus einem bestimmten Ordner nicht zulässt (den ich als separates Projekt auf Github übertragen könnte, die Änderungen aber sowohl im Master-Repo als auch im Sub-Repo angezeigt werden). Repos)

ICH könnte verwende das Git-Submodulsystem, aber es verhält sich auch nicht so, wie ich es möchte (Submodule sind Zeiger auf andere Repositorys und enthalten nicht wirklich den eigentlichen Code, daher sind sie für die Sicherung unbrauchbar).

Derzeit habe ich einen Ordner mit Git-Repos (zum Beispiel ~/code_projects/proj1/.git/ ~/code_projects/proj2/.git/), und nachdem ich Änderungen an proj1 vorgenommen habe, mache ich das git push github, dann kopiere ich die Dateien nach ~/Documents/code/python/projects/proj1/ und führe einen einzelnen Commit durch (anstelle der zahlreichen in den einzelnen Repos).Dann mach git push backupdrive1, git push mymemorystick usw

Also die Frage:Wie können Sie Ihren persönlichen Code und Ihre Projekte mit Git-Repositories nutzen und sie synchronisieren und sichern?

Answer 1

Ich würde stark Beraten Sie es, nicht verwandte Daten in ein bestimmtes Git -Repository zu setzen.Der Overhead der Schaffung neuer Repositories ist ziemlich niedrig, und das ist a Besonderheit Das ermöglicht es, verschiedene Abstammungslinien vollständig getrennt zu halten.

Das Kampf gegen diese Idee bedeutet, die Geschichte unnötig verwirrt zu werden, was die Verwaltung schwieriger macht und-was noch wichtig ist-"Archäologie" -Tools aufgrund der daraus resultierenden Verdünnung weniger nützlich macht.Wie Sie bereits erwähnt haben, geht Git davon aus, dass die "Einheit des Klonen" das Repository ist und dies aufgrund ihrer verteilten Natur praktisch tun muss.

Eine Lösung besteht darin, jedes Projekt/Paket/usw. beizubehalten.als sein eigenes nacktRepository (dh ohne Arbeitbaum) unter einer gesegneten Hierarchie, wie:

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

Sobald einige Konventionen festgelegt wurden, wird es trivial, administrative Operationen (Backup, Packung, Web Publishing) auf die vollständige Hierarchie anzuwenden, die eine Rolle dient, die den "monolithischen" SVN -Repositories nicht völlig unähnlich ist.Die Arbeit mit diesen Repositorys wird auch den SVNdürfen Verwenden Sie lokale Commits und Branches:

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

Sie können mehrere Fernbedienungen in jedem funktionierenden Klon haben, um die Synchronisation zwischen den mehreren Parteien zu synchronisieren:

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

Sie können dann von jeder der "Quellen" abrufen/ziehen, die lokal arbeiten und sich vor Ort verpflichten und dann ("Backup") in jede dieser Fernbedienungen schieben, wenn Sie mit so etwas wie dem vorbereiten (beachten Sie, wie das das schiebt, Dasselbe Kommt und Geschichte zu jedem der Fernbedienungen!):

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

Der einfachste Weg, ein vorhandenes funktionierendes Repository umzuwandeln ~/dev/fooin solch ein nacktes Repository ist wahrscheinlich:

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

was größtenteils einem entspricht svn import-Aber die bestehende "lokale" Geschichte wegwirft.

Notiz: Submodule sind ein Mechanismus zur gemeinsamen Einbeziehung verwandtLinien, daher würde ich sie in der Tat nicht als angemessenes Werkzeug für das Problem betrachten, das Sie lösen möchten.

Answer 2

Ich möchte etwas hinzufügen Damiens Antwort wo er empfiehlt:

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

Sie können eine spezielle Fernbedienung einrichten, um mit einem Befehl alle einzelnen echten Fernbedienungen anzusteuern.Ich habe es gefunden bei http://marc.info/?l=git&m=116231242118202&w=2:

Für "Git Push" (wo es sinnvoll ist, mehrmals die gleichen Zweige zu drücken) können Sie tatsächlich das tun, was ich tue:

• .git/config enthält:

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

• und nun git push all master wird den Zweig „master“ verschieben beide
  dieser Remote-Repositorys.

Sie können sich auch die doppelte Eingabe der URLs ersparen, indem Sie die folgende Konstruktion verwenden:

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

Answer 3

Ich bin auch neugierig auf vorgeschlagene Möglichkeiten, damit umzugehen, und werde das aktuelle Setup beschreiben, das ich verwende (mit SVN).Ich habe im Grunde ein Repository erstellt, das eine Mini-Dateisystemhierarchie einschließlich eigener Bin- und Lib-Verzeichnisse enthält.Im Stammverzeichnis dieses Baums befindet sich ein Skript, das Ihre Umgebung so einrichtet, dass diese Bins, Bibliotheken usw. hinzugefügt werden.andere Verzeichnisse den richtigen Umgebungsvariablen zuordnen.Das Stammverzeichnis sieht also im Wesentlichen so aus:

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

In /bin und /lib befinden sich nun mehrere Projekte und die entsprechenden Bibliotheken.Ich weiß, dass dies kein Standardprojekt ist, aber es ist für jemand anderen in meiner Gruppe sehr einfach, das Repo auszuchecken, das Skript „setup_env.bash“ auszuführen und die aktuellsten Versionen aller Projekte lokal in sich zu haben Kasse.Sie müssen sich nicht um die Installation/Aktualisierung von /usr/bin oder /usr/lib kümmern und es bleibt einfach, mehrere Checkouts und eine sehr lokalisierte Umgebung pro Checkout zu haben.Jemand kann auch einfach das gesamte Repository rammen und sich nicht um die Deinstallation irgendwelcher Programme kümmern.

Das funktioniert bei uns gut und ich bin mir nicht sicher, ob wir es ändern werden.Das Problem dabei ist, dass sich in diesem einen großen Repository viele Projekte befinden.Gibt es eine git/Hg/bzr-Standardmethode, um eine solche Umgebung zu erstellen und die Projekte in ihre eigenen Repositorys aufzuteilen?

Answer 4

Ich habe noch nicht versucht, Git-Repositorys zu verschachteln, da ich noch nicht auf eine Situation gestoßen bin, in der ich das tun müsste.Wie ich weiter gelesen habe #git-Kanal Git scheint durch die Verschachtelung der Repositorys verwirrt zu werden, d. h.Sie versuchen, in einem Git-Repository Git-Init durchzuführen.Die einzige Möglichkeit, eine verschachtelte Git-Struktur zu verwalten, besteht darin, beides zu verwenden git-submodule oder Android repo Dienstprogramm.

Was die Backup-Verantwortung betrifft, die Sie beschreiben, sage ich delegieren Es...Bei mir lege ich normalerweise das „Ursprungs“-Repository für jedes Projekt auf einem Netzwerklaufwerk am Arbeitsplatz ab, das von den IT-Technikern regelmäßig mit der Backup-Strategie ihrer Wahl gesichert wird.Es ist einfach und ich muss mir darüber keine Sorgen machen.;)

Answer 5

Wie wäre es mit der Verwendung? Herr zum Verwalten Ihrer mehreren Git-Repos gleichzeitig:

Der Befehl MR (1) kann andere Aktionen in einer Reihe von Repositories überprüfen, aktualisieren oder ausführen, als wären sie ein kombiniertes Respository.Es unterstützt eine beliebige Kombination aus Subversion, Git, CVS, Mercurial, BZR, DARCS, CVS, VCSH, Fossil und Richtigkeit, und die Unterstützung anderer Revisionskontrollsysteme kann leicht hinzugefügt werden.[...]

Es ist über einfaches Shell-Scripting äußerst konfigurierbar.Einige Beispiele für Dinge, die es tun kann, sind:

[...]

• Wenn Sie ein Git-Repository aktualisieren, ziehen Sie es von zwei verschiedenen Upstreams und führen Sie die beiden zusammen.
• Führen Sie mehrere Repository-Updates parallel aus, was den Update-Prozess erheblich beschleunigt.
• Merken Sie sich Aktionen, die fehlgeschlagen sind, weil ein Laptop offline war, damit Sie sie wiederholen können, wenn der Laptop wieder online ist.

Answer 6

Es gibt eine andere Methode für verschachtelte Git-Repos, die jedoch das gesuchte Problem nicht löst.Dennoch, für andere, die nach der Lösung suchen, war ich:

Verstecken Sie im Git-Repo der obersten Ebene einfach den Ordner in .gitignore, der das verschachtelte Git-Repo enthält.Dies macht es einfach, zwei separate (aber verschachtelte!) Git-Repos zu haben.