Verteilte Versionsverwaltung ohne Server

Hallo!

Bei meiner Suche nach einer für meinen Fall für SharpDevelop 4 geeigneten Versionsverwaltung bin ich auf Git gestoßen. Leider weiß ich noch nicht so recht, ob es das ist, was ich suche.

Ich suche eine Versionsverwaltung, die ohne Zugriff auf einen gemeinsamen Server betrieben werden kann. Die beteiligten Entwickler werden Daten nur per E-Mail, FTP oder USB-Stick austauschen können.
*Wäre das mit Git machbar? *Würde man das zentrale Repository an genau einem Standort halten? *Wie könnte man die verteilten lokalen Repositorys gegen das zentrale abgleichen? *Wie könnte man die Änderungen untereinander verteilen?

Beispiel:
Wenn ich es bislang richtig verstanden habe, erstellt Entwickler A ein Main-Repository und macht sich davon eine lokale Kopie. Wie kommt nun Entwickler B an ein lokales Repository? Kann A das erstellen und ihm zusenden? Oder muss A das Main-Repository weitergeben?

A und B machen Änderungen und spielen sie in ihr jeweiliges Repository zurück. Nach einigen Tagen sollen diese Änderungen untereinander und mit dem Main-Repository ausgetauscht werden, sodass alle Repositorys wieder auf dem neuesten Stand sind. Wie geht man dabei genau vor?

Für ein paar Tipps und Hinweise wäre ich sehr dankbar!

Hallo,

in einer verteilten Versionsverwaltung gibt es kein "zentrales" Repository in dem Sinne. Alle Repositories enthalten den kompletten Code UND die komplette Historie, und alle sind identisch.

In den meisten Fällen wird man ein Repository auf einen zentralen Server legen und sich mündlich darauf einigen daß das das "zentrale" ist, weil es einfach leichter zu handeln ist als E-Mail/FTP/USB-Stick.

Man kann natürlich auch ohne zentralen Server arbeiten, aber der Austausch über E-Mail/FTP/USB-Stick ist halt etwas umständlicher. Um bei Deinem Beispiel zu bleiben, würde Entwickler A am Anfang 1x das zentrale Repository weitergeben, Entwickler B und C würden ihm dann irgendwann ihre veränderten Versionen zurückschicken, und er würde ihre Änderungen per **Pull **in sein Repository holen und dort ggf. mergen.

Aber mal eine ganz andere Idee: warum suchst Du überhaupt eine Versionsverwaltung ohne Zugriff auf einen gemeinsamen Server?
Ist es zwingende Voraussetzung daß es keinen geben darf, oder hast Du einfach nur keinen zur Verfügung?

Wenn Du nur keinen zur Verfügung hast...es gibt genügend Anbieter bei denen man Repositories hosten kann.
Siehe Online Quellcodeverwaltung für private Projekte?.

Allerdings sind die meisten nur für Open Source-Projekte kostenlos (sprich, die Repositories sind öffentlich).
Wenn Dein Projekt nicht Open Source ist, würde ich Bitbucket empfehlen. Da bekommt man private Repositories für bis zu 5 User kostenlos.
Die benutzen als Versionsverwaltung allerdings nicht Git, sondern Mercurial.

Danke für Deine Antworten!

...in einer verteilten Versionsverwaltung gibt es kein "zentrales" Repository in dem Sinne. ...
In den meisten Fällen wird man ein Repository auf einen zentralen Server legen und sich mündlich darauf einigen daß das das "zentrale" ist ...

Das ist ein Punkt, den ich bislang zwar schon mehrfach gelesen, aber nicht wirklich verstanden habe: Wozu dient denn überhaupt das zentrale Repository? Vielleicht um die Unterschiede des zentralen gegenüber dem lokalen Repository zu kennen - und diese in der Folge dann anderen zur Verfügung zu stellen?

... Um bei Deinem Beispiel zu bleiben, würde Entwickler A am Anfang 1x das zentrale Repository weitergeben, Entwickler B und C würden ihm dann irgendwann ihre veränderten Versionen zurückschicken, und er würde ihre Änderungen per **Pull **in sein Repository holen und dort ggf. mergen.

Woher wissen B und C, welche Änderungen Sie noch nicht an A geliefert haben? Müssen sie sich das z. B. an einem Datum merken, oder "weiß" es das Git? "Pull" würde dann bedeuten, dass A sich die von B und C weitergeleiteten Differenzen(?) in sein lokales(?) Repository holen würde? Macht er sich dabei nichts kaputt?

Zu welchem Zeitpunkt gibt denn A seine Änderungen weiter? "Weiß" das lokale(?) Repository, welche Änderungen A noch nicht weitergereicht hat, und stören zwischenzeitliche "Pull"- und /oder "Merge"-Aktionen dabei nicht?

Dann noch zum "Mergen": Sollten A und B dieselben Dateien bearbeitet haben und es zu Konflikten kommen, dann hat der Mergende die Arbeit mit dem fremden Code? Nicht, dass ich davon "Angst" hätte; ich will 's nur wissen und verstehen.

Ach ja, "die Cloud" scheidet als Speicherort für die Daten aus. Da ist das Vertrauen noch nicht so weit ...

Hallo Harry B.,

und was spricht dagegen, wenn einer der Peer-Rechner doch die Server-Funktion übernimmt? Außer, dass er eingeschaltet sein muss, wenn die anderen darauf zugreifen wollen.

Wenn du sagst, dass FTP, also das File-Transfer-Protokoll, eine der Möglichkeiten ist, dann ist der Schritt dazu, das Transfer-Protokoll einer Versionsverwaltung zu verwenden nun auch nicht mehr so groß.

herbivore

Hallo

wir arbeiten bei uns in der Firma auch mit Git und sind sehr zufrieden damit. Es gibt ein "Master-Repository" auf einem Server, in das alle Entwickler arbeiten. Zusätzlich gibt es bei jedem Entwickler ein lokales Repository. Die Entwickler Committen in Ihr lokales Repository und pushen dann irgendwann ins Master. Wenn es dort schon Änderungen gegeben hat (weil ein anderer Entwickler inzwischen gepusht hat), dann meldet dies Git. Dann muss man zuerst ein Pull machen, damit man auf dem aktuellen Stand ist. Natürlich muss man bei Mergekonflikten händisch diese beseitigen. Ich glaube aber nicht, dass das bei anderen System anders ist. In der aktuellen "dotnetpro" (06/2011) sind mehrere Berichte über solche verteilten Versionsverwaltungssysteme enthalten.

Der große Vorteil von solchen Systemen ist, dass ich als Entwickler auch offline meine Commits und damit auch wieder Reverts machen kann.

Thomas

Danke für die Rückmeldungen!

@herbivore:

Nun, die beteiligten Enwickler befinden sich nicht innerhalb eines gemeinsamen Netzwerkes. Sie können sich nur über das Internet per E-Mail und FTP austauschen, oder ggf. falls mal per USB-Stick.

@thomas.at:

So, wie Du es beschreibst, habe ich es bislang ja auch verstanden. In meiner besonderen Situation ist es aber eben so, dass nur Entwickler A an seinem Standort auf das "Master-Repository" zugreifen kann bzw. soll.

Weiß den Git bei B und C (ohne auf das "Master-Repository" zugreifen zu können), was dort alles seit dem letzten Abgleich geändert wurde? Falls ja, dann schicken sie es halt an alle Beteiligten und jeder packt alles in sein lokales Repository. Nur A schiebt die Änderungen zusätzlich noch in das "Master-Repository". Wäre das möglich?
Wichtig wäre dabei, dass Git bei B und C "weiß", was alles noch nicht verschickt wurde, weil Menschen ja so schrecklich vergesslich sind.

Ach ja, "die Cloud" scheidet als Speicherort für die Daten aus. Da ist das Vertrauen noch nicht so weit ...

Die beteiligten Entwickler werden Daten nur per E-Mail, FTP oder USB-Stick austauschen können.

Auch wenn herbivore auch schon etwas dazu gesagt hat, ich formuliere es nochmal etwas deutlicher:

"Die Cloud" ist ein Rechenzentrum bei einem externen Anbieter, irgendwo im Internet.
Beim Datenaustausch per E-Mail oder FTP liegt Dein Code zwangsläufig auf dem Server Deines Providers...und der steht auch in einem Rechenzentrum bei einem externen Anbieter, irgendwo im Internet 😁

Was ich damit eigentlich sagen will: wenn Du Deinem Email- oder Webspaceprovider soweit vertraust daß Du Deinen Code per Mail oder FTP austauschst, dann kannst Du auch einem der großen Repository-Hoster wie Bitbucket oder GitHub vertrauen.

Und das Handling ist darüber wirklich wesentlich einfacher als über FTP/Mail.

Das ist ein Punkt, den ich bislang zwar schon mehrfach gelesen, aber nicht wirklich verstanden habe: Wozu dient denn überhaupt das zentrale Repository? Vielleicht um die Unterschiede des zentralen gegenüber dem lokalen Repository zu kennen - und diese in der Folge dann anderen zur Verfügung zu stellen?

Genau so ist es. Theoretisch geht es auch ohne zentrales Repository. Wenn ich mit 2 anderen Leuten zusammenarbeite und jeder sein eigenes Repository hat, dann kann ich mir auch aus den Repositories der beiden anderen deren Änderungen pullen.
Das ist aber etwas umständlich, denn je mehr Leute es sind, desto mehr Repositories gibt es, bei denen ich prüfen muß ob neue Änderungen drin sind. Außerdem ist es für Build- und Deploymentzwecke (Stichwort Buildserver, z.B.) sehr hilfreich wenn man nur ein zentrales Repository hat, von dem man genau weiß: da sind alle aktuellen Änderungen drin.
Ohne zentrales Repository muß man nämlich erstmal herausfinden, welcher der 3 Entwickler die aktuellste Version des Codes hat.

Woher wissen B und C, welche Änderungen Sie noch nicht an A geliefert haben? Müssen sie sich das z. B. an einem Datum merken, oder "weiß" es das Git? "Pull" würde dann bedeuten, dass A sich die von B und C weitergeleiteten Differenzen(?) in sein lokales(?) Repository holen würde? Macht er sich dabei nichts kaputt?

Pull heißt genau das.
Push wäre, daß B und C ihre Änderungen stattdessen in ein anderes Repository "schieben" würden. Dafür benutzt man normalerweise ein zentrales.
Git & Co sind schlau genug um sich intern zu merken was sie schon alles gepusht/gepullt haben und was nicht. Deshalb werden bei jedem Push/Pull wirklich nur die Daten gesendet/geholt die wirklich neu sind.
Und nein, man macht sich damit nichts kaputt. Jedes Repository hat lokal eine komplette Historie. Wenn man pullt, werden die Änderungen erstmal nur in der Historie gespeichert, sonst nichts.
Wenn man die Änderungen wirklich in den Codedateien in seiner lokalen Version sehen will, muß man sie explizit aktualisieren. Da kann also auf keinen Fall etwas automatisch überschrieben werden.

Dann noch zum "Mergen": Sollten A und B dieselben Dateien bearbeitet haben und es zu Konflikten kommen, dann hat der Mergende die Arbeit mit dem fremden Code? Nicht, dass ich davon "Angst" hätte; ich will 's nur wissen und verstehen.

Jawoll, der Mergende hat die Arbeit.
So schlimm ist das aber nicht, bei Git & Mercurial ist das Mergen wesentlich einfacher als z.B. bei Subversion. Sogar wenn zwei Leute die gleiche Datei bearbeitet haben, sind Git & Mercurial clever genug um das von alleine zu lösen. Es gibt nur einen einzigen Fall in dem der User wirklich etwas manuell machen muß, nämlich wenn beide **die gleiche Zeile **in der gleichen Datei bearbeitet haben.

In meiner besonderen Situation ist es aber eben so, dass nur Entwickler A an seinem Standort auf das "Master-Repository" zugreifen kann bzw. soll.

OK, das war bis jetzt noch nicht so deutlich. Du willst also, daß Entwickler A das Master-Repository verwaltet und B und C ihm nur zuarbeiten und ihm ihre Änderungen schicken?
Falls ja: das hört sich nach dem typischen Open Source-Projekt-Workflow an.
Der sieht, auf Dein Beispiel gemünzt, ungefähr so aus:

Entwickler A hat ein Repository bei Github/Bitbucket/wasauchimmer.
Das ist das Master-Repository. Entwickler A hat Schreibzugriff, B und C haben nur Lesezugriff.

B und C können sich jederzeit eine Kopie vom Master-Repository machen.
Da gibt es 2 Varianten:
"Clone" --> Kopie auf den lokalen Rechner
"Fork" --> sie müssen auch einen Account beim gleichen Hoster haben. Dann haben sie eine Kopie online, und die können sie wiederum auf ihren lokalen Rechner klonen und dort bearbeiten. Wozu das gut ist, kommt gleich noch.

Dann können sie lokal ihre Änderungen machen.
Wenn sie die fertig haben, committen sie sie. Dann sind die Änderungen in ihren lokalen Repositories.
Jetzt müssen die Änderungen irgendwie in das zentrale Master-Repository. Schreibzugriff darauf hat nur A. Also müssen B und C ihre Änderungen irgendwie an A schicken.

Dafür gibt es 2 Möglichkeiten:
Wenn sie das Repository nur lokal geklont haben, können sie aus ihren Änderungen einen Patch erzeugen. Das ist eine Textdatei die die geänderten Stellen mit Änderungskommentar usw. enthält.
Die schicken sie per Mail an A, und der kann sie in sein Repository importieren.
Oder, wenn B und C einen Fork auf Github/Bitbucket haben: dann pushen sie ihre Änderungen einfach dahin und sagen A, daß er sich ihre Änderungen von dort holen soll.
A kann sich die Änderungen direkt aus den Repositories von B und C pullen (Lesezugriff muß er natürlich haben) und angucken, in seinem lokalen Repository committen und dann ins Master-Repository pushen.

Und dann machen B und C wieder einen Pull vom Master-Repository, und beide haben die jetzt aktuelle Version.

Das ist der typische Ablauf bei den meisten Open Source-Projekten.
Nur wenige Leute haben tatsächlich Schreibzugriff, aber jeder kann sich den Code holen, Änderungen machen und diese an einen von den Leuten mit Schreibzugriff schicken.

Dafür mußt Du Dich allerdings mit dem Gedanken anfreunden, Dein Repository in der Cloud zu speichern.
Wenn Du das nicht möchtest, kannst Du den gleichen Workflow auch nachbauen indem Du Daten per Mail/FTP austauschst, es ist halt nur viel umständlicher als Push/Pull.

Hallo Harry B.,

Sie können sich nur über das Internet per E-Mail und FTP austauschen, oder ggf. falls mal per USB-Stick.

wenn sie sich über das Internet austauschen können, können sie das wohl auch über das Protokoll einer Versionsverwaltung. Der Rechner, auf dem die Daten liegen, kann ja trotzdem einer der Peer-Rechner sein. Die Daten müssen nicht bei einem Dritten liegen.

Wobei haarrrgh ja schon angemerkt hat, dass schon bei der Datenübertragung und erst recht bei der Nutzung eines E-Mail-Providers die Daten mindestens über die Cloud übertragen werden oder sogar in der Cloud liegen.

Ich bin ja auch kein Fan besonderer der Cloud und überlege mir sehr genau, welche Daten ich ins Netz stelle und welche nicht. Aber man kann es mit der Paranoia auch übertreiben. 😃

herbivore

Noch einmal herzlichen Dank für die Informationen!

Ich denke, dass ich jetzt erst einmal mit einem Beispiel beginne, um auch die Git-Handhabung kennenzulernen. Dann werde ich sehen, wie weit ich komme und mich dann noch einmal hier melden.