Verwendung von Git auf mehreren Systemen ohne Netzwerkzugriff


84

Ich möchte die Versionskontrolle verwenden, aber aus Sicherheitsgründen hat der Server, an dem ich arbeite, keinen Internetzugang: Ich kann nur Dateien auf einem USB-Stick verschieben. Kann ich Git mit diesem Setup weiterhin verwenden? Kann ich kleine Patches erstellen, die ich auf ein Git-Repository anwenden kann?


65
In Ihrem Titel steht kein Netzwerkzugriff, in Ihrer Frage steht kein Internetzugang. ein großer Unterschied.
Tkausl

7
@TutuKaeen Sie können ein lokales Netzwerk haben, das nicht mit dem Internet verbunden ist. Anstelle von github.com richten Sie also den Git-Server ein, z. 192.168.1.100 und alles andere funktioniert gleich.
Agent_L

12
@TutuKaeen: Die entscheidende Frage ist, ob eine direkte (oder indirekte) Netzwerkkommunikation zwischen den beiden Computern möglich ist. In Ihrem Fall sind also beide Maschinen vernetzt, aber die Netzwerke sind getrennt? In diesem Fall bearbeiten Sie diese Informationen bitte in Ihre Frage.
sleske

15
@TutuKaeen Deine Frage bleibt unklar. Sie möchten die Versionskontrolle verwenden, in Ihren Kommentaren wird jedoch eine Unterstützung für die Bereitstellung in der Produktion benötigt. Diese Probleme überschneiden sich nicht immer. Ich denke, Sie haben unten gute Antworten, aber in Zukunft wäre es hilfreich, wenn Ihre Frage umfassender zu Ihren Anforderungen wäre. Diese lauten anscheinend: "Ich möchte die Versionskontrolle verwenden, mein Entwicklungscomputer hat keinen Internetzugang." Es hat zwar Netzwerkzugriff, aber keinen Zugriff auf die Produktionsmaschine, und ich möchte wissen, wie Code aus der Versionskontrolle auf die Produktionsmaschine übertragen werden kann. "
DavidS

4
Es scheint nur seltsam, den Begriff serverfür eine Maschine zu verwenden, die nicht mit einem Netzwerk verbunden ist. Es könnte auch ohne Internetzugang nur ein lokales Netzwerk sein, aber es ist trotzdem ein Netzwerk.
Patrick Gregorio

Antworten:


157

Klar, es gibt nichts an Git, das ein bestimmtes Protokoll erfordert. Nur aus der Box unterstützt die Standard - Client - HTTP (S), SSH, das benutzerdefinierten Git - Protokoll und, besonders wichtig, das lokale Protokoll. Dies erfordert lediglich einen Pfad zu einem lokalen .gitVerzeichnis, das sich innerhalb des Arbeitsverzeichnisses ( /path/to/project/.git) oder nur eines leeren Verzeichnisses ( /path/to/project.git) befinden kann, obwohl die Benennung nur eine Konvention ist.

Das heißt, Sie können natürlich ein Flash-Laufwerk als Fernbedienung hinzufügen:

git remote add origin /mnt/flashdrive/foo.git

oder unter Windows:

git remote add origin F:\foo.git

Oder fügen Sie es als zusätzliche Fernbedienung mit einem anderen Namen hinzu (wenn Sie lieber originauf einen Internetserver verweisen möchten ):

git remote add flashdrive /mnt/flashdrive/foo.git

Dann können Sie wie bei jeder anderen Fernbedienung einfach auf diese drücken / ziehen.

Wenn Sie die Dokumentation lesen , werden Sie feststellen, dass es auch ein file://Protokoll gibt, das sich etwas anders verhält. Es wird empfohlen, einen lokalen Pfad zu verwenden, da dies einige zusätzliche Optimierungen erfordert. Wenn Sie das file://Protokoll verwenden, verwendet git einige Standardnetzwerkkomponenten (um mit der lokalen Festplatte zu kommunizieren), die langsamer sind.


50
Um diese außergewöhnliche Antwort zu ergänzen: Es kann sich auch lohnen, die Verwendung eines "leeren" Speicherorts auf dem Flash-Laufwerk zu untersuchen. 'Nackte' Repositorys haben keinen Arbeitsbaum, und daher sollten Sie eine Kategorie potenzieller Probleme herausschneiden, wenn Sie als gemeinsamer 'Autoritätspunkt' verwendet werden, was sich nach dem Anwendungsfall des OP anhört.
Iron Gremlin

5
Das file://ist auch etwas flexibler. Hiermit können Sie einige Funktionen verwenden (z. B. flache Klone), die Sie mit einem lokalen Pfad nicht verwenden können.
Austin Hemmelgarn

1
@IronGremlin Könnten Sie diesen Begriff "Shared Point of Authority" erweitern? Ich bin kein Git-Experte und neugierig, was Sie damit meinen.
Leichtigkeitsrennen im Orbit

2
@LightnessRacesinOrbit - Dies ist ein ziemlich dichtes Thema, aber im Grunde ist Git verteilt, so dass jeder seine eigene Geschichte bekommt. A kann B nach seiner Version der Geschichte fragen, aber C weiß nichts davon, es sei denn, jemand sagt es ihnen. Ein einziges Repository zur Speicherung der 'maßgeblichen' Historie bedeutet, dass D als Clearing-Stelle für Historien fungiert. Also erzählt A D von Veränderungen, und B und C wissen, dass sie mit D sprechen müssen, um auf dem Laufenden zu bleiben, anstatt Side-Channel-Angelegenheiten untereinander zu erledigen. Beispiel: Wenn der OP-Server C und das Flash-Laufwerk D ist, wird sichergestellt, dass der Server nicht von A / B-Interaktionen ausgeschlossen wird.
Iron Gremlin

6
@LightnessRacesinOrbit Wichtig ist hier zu beachten, dass nacktes nicht autorisierend bedeutet, es ist nur in diesem Zusammenhang nützlich. Zum Beispiel ist es auch nützlich, weil es keinen Arbeitsbaum gibt und der Speicherplatz (oder die Bandbreite) kleiner ist. Früher war das um einiges wichtiger als heute, aber es kommt immer noch auf.
Iron Gremlin

46

Auf einem einzelnen Computer ist nichts Besonderes erforderlich. Führen git initSie das gewünschte Verzeichnis aus und arbeiten Sie wie gewohnt mit Git.

Es gibt verschiedene Methoden, um ein Repository über mehrere Computer hinweg zu synchronisieren .

Methode 1a (überhaupt kein Netzwerk): Sie können ein 'Bare Repository' auf dem USB-Stick erstellen, darauf drücken und daraus ziehen, wie Sie es mit jedem anderen Remote-Repository tun würden. Mit anderen Worten, Repository-Vorgänge über lokale Pfade unterscheiden sich nicht von Vorgängen über SSH- oder HTTPS-URLs.

  1. Erstellen Sie ein 'Remote'-Repository:

    $ git init --bare /mnt/Stick/Repositories/Large_Project.git
    
  2. Übertragen Sie auf Computer 1 alles darauf:

    $ cd ~/Large_Project
    $ git remote add usb /mnt/Stick/Repositories/Large_Project.git
    $ git push usb master
    
  3. In Computer 2 nun, wie immer.

    $ git remote add usb /mnt/Stick/Repositories/Large_Project.git
    $ git pull usb
    

(Sie können auch direkt von einer URL oder einem Pfad aus pushen / holen / ziehen.)

Methode 1b (internes Netzwerk): Wenn ein interner Server mit SSH verfügbar ist und Git installiert ist, können Sie dasselbe wie oben tun, indem Sie einfach eine SSH-Adresse mithilfe der Syntax [user@]host:pathoder angeben ssh://[user@]host/path.

  1. Erstellen Sie ein Remote-Repository, indem Sie es git init --bare <somepath.git>auf dem angegebenen Server ausführen (über SSH).

  2. In Computer 1 auf dieselbe Weise wie zuvor gezeigt.

    $ git remote add origin myserver.example.com:Gits/Large_Project.git
    

    Oder wenn Sie es vorziehen:

    $ git remote add origin ssh://myserver.example.com/Gits/Large_Project.git
    
  3. In Computer 2 wieder dasselbe wie in Methode 1a.


Methode 2: Sie können "Transfer-Bundles" erstellen, die eine bestimmte Liste von Commits in einer einzigen Datei archivieren.

Leider merken sich die Bundle-Befehle nicht automatisch, was das letzte Mal bereits gebündelt wurde, sodass manuelles Markieren oder Notieren erforderlich ist. Ich nehme nur die Beispiele aus dem Git-Bundle-Handbuch.

  1. Erstellen Sie auf Computer 1 ein Bündel der gesamten Verzweigung:

    $ cd ~/Large_Project
    $ git bundle create /mnt/Stick/Project.bundle master
    $ git tag -f last-bundled master
    
  2. Ziehen Sie auf Computer 2 aus dem Bundle, als wäre es ein Repository:

    $ cd ~/Large_Project
    $ git pull /mnt/Stick/Project.bundle
    

Nachfolgende Bundles müssen nicht das ganze packen master- sie können last-bundled..masterstattdessen nur die neu hinzugefügten Commits von packen .

  1. Erstellen Sie auf Computer 1 ein Bündel der neu hinzugefügten Commits:

    $ cd ~/Large_Project
    $ git bundle create /mnt/Stick/Project.bundle last-bundled..master
    $ git tag -f last-bundled master
    
  2. Das gleiche wie oben.


eigentlich wäre es nicht schlecht für meine zwecke, auch in git ist nichts "primär", da jedes repository die gesamte geschichte hat, so dass du es jedes mal neu erstellen kannst, wenn etwas
schief

manual tagging or note-keeping is needed, eine Option, wenn das Repo nicht sehr groß ist git bundle create my.bundle --all, ist
:,

Ich mag diese Antwort mehr, da sie illustrativer ist, obwohl die akzeptierte Antwort und dies dasselbe aussagt.
Rystraum

Welche Bedeutung hat die Option "nackt"?
Leichtigkeitsrennen im Orbit

1
Es erstellt ein Repository, das nur die Datenbank ist (was normalerweise im .git/versteckten Ordner zu finden ist), ohne einen "Arbeitsbaum" (die bearbeitbaren Dateien). Dies ist die bevorzugte Form für Repositorys, die Sie verwenden git push.
Grawity

20

git bundle create

Eine der Methoden besteht darin, externen Speicher zum Austausch von Daten zwischen Repositorys zu verwenden. Dies ist ein Git-Bundle . Auf diese Weise haben Sie nur einzelne Dateien für jede Übertragung, keine Git-Zwischenablagen.

Jeder "Git Push" verwandelt sich in die Erstellung einer Datei, "Git Fetch" holt Dinge aus dieser Datei.

Demo-Sitzung

Erstellen des ersten Repositorys und Ausführen des ersten "Push"

gitbundletest$ mkdir repo1

gitbundletest$ cd repo1

repo1$ git init
Initialized empty Git repository in /tmp/gitbundletest/repo1/.git/
repo1$ echo 1 > 1 && git add 1 && git commit -m 1
[master (root-commit) c8b9ff9] 1
 1 file changed, 1 insertion(+)
 create mode 100644 1

repo1$ git bundle create /tmp/1.bundle master HEAD
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 384 bytes | 384.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)

"Klonen" in das zweite Repository (dh den zweiten Computer):

gitbundletest$ git clone /tmp/1.bundle repo2
Cloning into 'repo2'...
Receiving objects: 100% (3/3), done.

gitbundletest$ cd repo2/

repo2$ cat 1
1

Einige Änderungen vornehmen und in eine andere Bundle-Datei "verschieben":

repo2$ echo 2 > 1 && git add 1 && git commit -m 2
[master 250d387] 2
 1 file changed, 1 insertion(+), 1 deletion(-)

repo2$ git bundle create /tmp/2.bundle origin/master..master origin/HEAD..HEAD
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 415 bytes | 415.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)

Änderungen in das erste Repository "ziehen":

repo2$ cd ../repo1

repo1$ git pull /tmp/2.bundle 
Receiving objects: 100% (3/3), done.
From /tmp/2.bundle
 * branch            HEAD       -> FETCH_HEAD
Updating c8b9ff9..250d387
Fast-forward
 1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

repo1$ cat 1
2

Im Gegensatz zum ersten Bundle enthält das zweite nur einen Teil der Git-History und ist nicht direkt klonbar:

repo1$ cd ..

gitbundletest$ git clone /tmp/2.bundle repo3
Cloning into 'repo3'...
error: Repository lacks these prerequisite commits:
error: c8b9ff94942039469fa1937f6d38d85e0e39893a 
fatal: bad object 250d38747656401e15eca289a27024c61e63ed68
fatal: remote did not send all necessary objects

Die Verwendung von Bundles hat den Nachteil, dass Sie manuell angeben müssen, welchen Bereich von Commits jedes Bundle enthalten soll. Im Gegensatz zu git push, git bundlezu verfolgen , was in früherem Bündel war nicht, müssen Sie manuell einstellen refs/remotes/origin/masteroder Bündel würde größer sein , als es sein könnte.


Vergiss nicht die --allFlagge zu erwähnen , um alles zu bekommen. Wenn das Repo klein genug ist, ist dies der einfachste Vorgang, da Sie einfach jedes Mal alles übertragen! Verlieren Sie nur nicht den Memory Stick - wahrscheinlich das größte Sicherheitsproblem!
Philip Oakley

7

Sie müssen zuerst Git installieren . Führen Sie dann zum Erstellen eines neuen Repositorys den Ordner aus, den Sie kopiert haben:

git init

Anschließend können Sie Dateien hinzufügen, über die Sie die Versionskontrolle durchführen möchten git add( -afür alle Dateien hinzufügen ), und die Änderungen übernehmen ( git commit).

Sie müssen sich nicht an eine Fernbedienung wenden, da Sie an Ihrem lokalen Verlauf arbeiten können ( git log).

Weitere Informationen finden Sie unter:


Schieben / Ziehen ohne Internet

Mit dem git pushBefehl ist es möglich, über SSH zu pushen (über lokale Verbindung, Intranet):

git remote add server ssh://[user@]host.xz[:port]/path/to/dev/repo.git/
git push server

oder in den Ordner schieben:

git push /mnt/usb/my_repo

Dies setzt voraus, dass Sie zwei Kopien Ihres Repositorys haben.

Gleiches gilt beim Ziehen, z

git pull /mnt/usb/my_repo

Patchen

Zum Anwenden von Patches können Sie den patchBefehl oder verwenden git apply.

Siehe: Patch- oder Diff-Datei aus dem Git-Repository erstellen und auf ein anderes Git-Repository anwenden .


5

Sie können Git auch lokal verwenden. Dann werden Ihre Commits nur lokal gespeichert und Sie haben immer noch die Versionskontrolle (und können unterscheiden / zusammenführen usw.), aber Sie können von keinem anderen Computer aus auf das Repository zugreifen.

Sie können ein lokales Git-Repository starten, indem Sie es git initin Ihrem lokalen Ordner ausführen. Wie hier beschrieben .


3
Das weiß ich, aber ich möchte auf einem anderen Computer arbeiten und es auf Dateien auf einem Server ohne Internetzugang
anwenden

2
@TutuKaeen Ich sehe nichts falsches daran, das Repository auf einem Flash-Laufwerk zu haben und es einfach auf Festplatten von verschiedenen Computern zu klonen / zu synchronisieren. "Server ohne Internetzugang" klingt jedoch seltsam. Das Ziel eines Servers besteht darin, einen Dienst bereitzustellen. Meistens bezieht sich der Dienst auf das Netzwerk (aber nicht immer).
AnonymousLurker

2
@dhae - Bitte nehmen Sie sich einen Moment Zeit, um weitere Informationen zur lokalen Verwendung von Git zu erhalten. Nur anzuzeigen, dass dies möglich ist, ist für eine Antwort nicht hilfreich.
Ramhound

2
@anonymousLurker Das Serving dient dazu, Daten an ein geschlossenes Netzwerk in einer sehr wichtigen Institution zu liefern. Es dient dem breiten Internet einfach nichts, da die Daten sehr heikel sind und nur für die Mitarbeiter.
Tutu Kaeen

1
@TutuKaeen: Wenn es einen Netzwerkzugriff gibt, können Sie jederzeit Ihren eigenen Git-Server über SSH betreiben. Git hat mehr zu bieten als nur GitHub.
Grawity
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.