Bare-Bones-Browser
git instaweb --httpd=webrick
von der git scm buch
es mit einem ähnlichen Ansatz wie dem beschriebenen zu kombinieren aquí für die verteilte Entwicklung (Dank an datagrok für das gut beschriebene Konzept)
Starten Sie einen einmaligen Git-Server von einem beliebigen lokalen Repository aus.
I hat dies bereits getwittert aber ich dachte, es könnte eine Erweiterung gebrauchen:
Aktivieren des dezentralen Git-Workflows: git config alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"
Angenommen, Sie verwenden einen Git-Workflow, bei dem Sie mit einem "offiziellen" Kern-Repository arbeiten, aus dem Sie Ihre Änderungen herausziehen und in das Sie sie hineinschieben. Ich bin sicher, dass viele Unternehmen dies tun, ebenso wie viele Nutzer von Git-Hosting-Diensten wie Github.
Angenommen, der Server oder Github fällt für eine Weile aus.
Keine Sorge, schließlich ist einer der Gründe für die Verwendung von git, dass Sie eine Kopie des gesamten Projektverlaufs in Ihrem lokalen Klon haben.
Sie können mit dem Programmieren und Übertragen weitermachen, während Sie darauf warten, dass das Betriebsteam den Server wieder zum Leben erweckt. Notiz an mich selbst: Kaufen Sie Doughnuts für das Betriebsteam.
Was aber, wenn Sie während dieser Ausfallzeit mit einer anderen Person, die vielleicht kein Git-Experte ist, an demselben Repository zusammenarbeiten möchten?
Oder wie wäre es, wenn Sie und Ihr Kollege vor Ort sind und aus irgendeinem Grund Ihr VPN keine Verbindung zu Ihrem offiziellen Projektarchiv zulässt?
Oder was ist, wenn Sie und Ihr Kollege einen Haufen experimenteller Änderungen vornehmen, und obwohl Sie Zugang haben, wollen Sie Ihr unfertiges Chaos nicht in das offizielle zentrale Repository verschieben? (Nicht einmal als Feature-Zweige.) Vielleicht sind Sie gerade dabei, einen katastrophalen Rebase oder Merge zu bereinigen und die Zweige sind überall verstreut.
Nun, git ist, wie Sie wahrscheinlich wissen, ein "verteiltes" Versionskontrollsystem .
Auch wenn Sie in Ihrem Arbeitsablauf ein zentrales "offizielles" Git-Repository verwenden, haben Sie dennoch die Möglichkeit, Git auf Peer-to-Peer-Basis zu nutzen, d. h. Sie und Ihr Kollege erstellen und tauschen Commits untereinander aus, ohne dass der zentrale Server davon Kenntnis erhält.
Wie bekommen Sie also Ihre Branches und Commits zu ihnen hinüber oder umgekehrt?
- Sie könnten die Möglichkeiten von Git nutzen, um Patches per E-Mail zu versenden. Aber das ist etwas umständlich und erfordert ein gewisses Wissen darüber, wie man per E-Mail verschickte Patches anwendet.
- Sie könnten auf Ihrem eigenen Rechner ein Konto einrichten, in das sich Ihr Mitarbeiter per SSH einloggen kann. Aber vielleicht haben Sie keinen lokalen Root-Zugang, oder Sie trauen ihm den SSH-Zugang zu Ihrem Rechner nicht zu.
- Sie könnten Ihr Repo auf einen Thumbdrive klonen und es hin- und herschieben. Aber das ist ziemlich mühsam, vor allem, wenn Sie sich im selben lokalen Netzwerk befinden, und erfordert einen USB-Stick.
Wahrscheinlich fallen Ihnen auch noch andere Methoden ein. Aber es gibt einen einfachen Weg: Wenn Sie sich im Netzwerk sehen können, können Sie einen einmaligen Git-Server starten, den der andere als Remote-Server verwenden kann, um Ihre Änderungen zu klonen, zu holen und zu ziehen, und ihn zu beenden, wenn Sie damit fertig sind.
Das Werkzeug, das dies ermöglicht, ist git daemon die eine Menge Optionen und Funktionen hat, aber für den Zweck der Ermöglichung dieser einfachen einmaligen "servieren Sie einfach die Repo ich bin in," der Weg, um es zu benutzen ist, um einen Alias zu erstellen. Ich nenne ihn gerne git serve . Laufen:
git config --global alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"
Die Verwendung eines Alias ist sehr wichtig, da Git-Aliase im Basisverzeichnis Ihres Arbeitsbaums ausgeführt werden. Der Pfad ".git" verweist also immer auf die richtige Stelle, egal wo Sie sich im Verzeichnisbaum Ihres Repositorys befinden.
Verwenden Sie Ihr neues git serve etwa so:
- Exécuter
git serve . "Bereit zum Rumpeln", meldet es. Git ist knallhart.
- Finden Sie Ihre IP-Adresse heraus. Sagen wir, sie lautet 192.168.1.123.
- Sagen Sie: "Hey Jane, ich bin nicht bereit/fähig, diese Commits nach Origin zu pushen, aber du kannst meine Commits in deinen Klon holen, indem du
git fetch git://192.168.1.123/ "
- Presse ctrl + c wenn Sie das Repo nicht mehr bedienen wollen.
Sie könnten Jane auch sagen, dass sie git clone git://192.168.1.123/ local-repo-name wenn sie noch keinen Klon des Repositorys hat. Oder, verwenden Sie git pull git://192.168.1.123/ branchname um einen Fetch und Merge auf einmal durchzuführen, was nützlich ist, wenn Sie gemeinsam an einem Feature-Zweig arbeiten.
Beachten Sie jedoch, dass Sie dies nicht in feindlichen Netzwerken tun sollten, wenn Sie Geheimnisse in Ihrem Repository aufbewahren, da es keine Authentifizierung gibt. Es kündigt seine Existenz nicht an, aber jeder mit einem Port-Scanner kann es finden, sich mit ihm verbinden und Ihr Repository klonen.
Aber es ist nicht besonders gefährlich, weil es standardmäßig schreibgeschützt ist. Lesen Sie die git daemon man-Seite sorgfältig, wenn Sie Schreibzugriff aktivieren wollen. Für den Fall, dass Sie die Commits Ihrer Kollegen erhalten wollen, ist es viel sicherer, sie schreibgeschützt zu lassen und Ihre Kollegen zu bitten, diesen Befehl ebenfalls auszuführen, damit Sie von ihnen lernen können.
In diesem Zusammenhang: Wenn Sie vorübergehend eine Reihe von statischen Dateien über HTTP freigeben möchten, sollten Sie sich mit dem Thema einmalige Server befassen: python -m SimpleHTTPServer
