Hallo Dirk, hey, das klingt doch schon ganz gut!
Ich will für die Leser mal kurz einige Begrifflichkeiten erklären:
(Es mag im Folgenden vieles kompliziert klingen, aber es ist WIRKLICH leicher als gedacht ;-))
- Was ist ein "Repository"?
Ein Repository ist quasi der Datenbestand - die Datenbank, die zwangsläufig an der Versionskontrolle hängt. Ein Repository verwaltet Projekte / Module. Das Repository liegt auf einem Server und in der regel nicht zu Hause auf dem heimischen PC, obschon man das auch machen kann um seine projekte lokal zu versionieren - das ist übrigens ganz interessant für lokale "Spielwiesen" und zum testen um mal das Arbeiten in einem Versionskontrollsystem zu üben, ohne etwas kaputt zu machen... ;-)
- Was ist das "Working Directory"?
Das Working Directory ist der Bereich, lokal auf Deinem PC - Quasi das Verzeichnis auf dem Du arbeitest (Deswegen auch der Namenszusatze "Working"). In diesem "Working Directory" checkt man sein Projekt / Modul aus dem Repository aus und comitted (checkt ein) seine Änderungen wieder und führt damit seine Änderungen zurück in die Versionskontrolle. Dabei wird den Änderungen eine neue Version gegeben.
- Hinzufügen und löschen von Modulen: Generell weiss das Repo erst mal gar nicht, welche Dateien es denn zu verwalten hat. Dazu muss man neue Files erst einmal per "Add" hinzufügen und diese dann committen. Ab dann sind sie teil der Versionierung! Soll eine Date / Dateien aus der version entfernt werden, dann muss man die "deleten" und danach auch diese Transaction comitten (Wichtig!).
Wichtig in dem Zusammenhang ist zu verstehen, dass ein Delete das File eigentlich physikalisch nie aus dem repository löscht! Es wird nur ab dieser version nicht mehr da sein. im Repo-Browswer kann man deshalb, wenn man in den versionen zurückgeht sehen, dass das File wieder da ist! Daher ist die Angst "Oh Gott, ich habe ein File aus dem Repository gelöscht" nicht zutreffend, denn man löscht da File zwar ab dieser Version, kann es aber in der Version zuvor wieder herstellen! Passiert einem das also (ist mir auch schon für ganze Verzeichnisse passiert ;-)) dann kann man einfach wieder eine Verion zurücgehen (auschecken einer bestimmten Version) und schon sind die Datein wieder da! Danach neu eincheken und schon hat man den fehelrhaften Delete wieder aufgehoben.
- Einchecken / Auscheken / Updaten. Alle Änderungen die man an einem Modul vornimmt finden ja erst mal nur lokal im Working Directory statt. Sprich davon merken zuerst die Anderen, die auch mit dem Modul(en) auf ihren Working Directories parallel arbeiten nichts! Man ist also ungestört in seiner "Sandbox" unterwegs und kann lustig vor sich hin werkeln ohne bei den Anderen was "kaputt zu machen" ;-)
Will man nun aber diese Änderungen für Alle verfügbar machen, dann muss man diese wieder in das Repository "comitten" (Zurückführen / Einchecken). Dies ist auch der Moment in dem man einen "Logging-Kommentar" eingeben sollte, der möglichst kurz beschreibt, was denn geändert wurde. Diese Änderung wird dann vom Versionskontrollsystem als eine neue Version gespeichert und fortan werden Andere User, wenn sie auschecken auch diese Änderungen bekommen. (Siehe auch "Mergen" / "Konflikte", wenn das Modul schon da war.)
Im Gegenzug bekommt man lokal erst mal nichts davon mit, wenn jemand schon Änderungen eingecheckt hat. Die muss man erst synchronisieren indem man ein "update" macht. Dann wird im repo geschaut, ob es schon von Anderen Usern / Commits Änderungen gibt und wenn dem so ist, werden die mit dem aktuellen Stand zusammengeführt. Dabei kann wieder die Problematik des "Mergen" ins Spiel kommen. Solange aber keine Kollisinen auftreten wird das Versionskontrollsystem alle Änderungen automatisch zusammenführen und man hat lokal dann die Vereinigte Menge der loakeln Änderungen + die der Anderen. Bedenke aber, dass diese Schnittmenge erst eingecheckt werden muss, wenn man will, dass die Eigenen Änderungen auch die Anderen bekommen.
- "Reverten" bedeutet, dass man die lokalen Änderungen absichtlich verwerfen will, indem sie durch die aktuelle Version aus dem Versionskontrollsystem überschrieben wird. Achtung! Dabei gehen wirklich alle lokalen Änderungen, die man noch nicht eingechekt hat VERLOREN. Also vorher gut nachdenken! ;-)
- Der "Repository Browser" ermöglicht wie der Name schon sagt das Navigieren im Repository. Hier sieht man alle Module, kann sich in den Versionen - also quasi in der Zeit zurück bewegen, kann auch von einer Version einen "Branch" erzeugen, welcher dann eigenständig versioniert wird etc. Hier sieht man auch wer wann welche Änderungen vorgenommen hat. Man kann so auch Änderungen aus einer bestimmten Version zurückholen. oder auch sagen - Ich möchte von einem Modul eine bestimmte Version in meinem Working Directory haben.
- Branches sind Abzweigungen vom Hauptentwicklungsszweig. Der Hauptentwicklungszweig heisst übrigens "Trunk" (Stamm). Ein Branch ermöglicht - wie bei einem Baum - das Abzweigen von einem anderen Branch - also mindestens vom Trunk. Wenn ich von "abzweigen" rede, dann meint das, dass man bei einer bestimmten Version (Stand des Modules) abknickt und basierend auf dieser Änderung einen neuen Versionszweig aufmacht. Das macht z.B. Sinn, wenn man z.B. Ein neues Feature implementieren möchte, welches man aber noch nicht wirklich in den Hauptzweig zurückführen will, weil dies u.U. noch nicht stabil ist. Dann entwickelt man (oder das Team) eben an diesem Branch weiter und stört nicht die Entwicklumg im Trunk. Man sagt dazu auch, dass man einen "Featurebranch" aufmacht, auf dem ein gewisses Feature quasi isoliert implementiert wird.
- Tags: Man kann Branches auch als sog. "Tags" markieren, nämlich. Das sind dann Versionsstände die man vorzugsweise als "Markierungen" für stabile / releaste Versionen / Meilensteine verwendet. Wenn man einen Branch als "Tag" markiert wird diese Version in diesem Ast aber sozusagen "festgenagelt", das heisst, einen Tag kann man nur auschecken, aber keineÄnderungen mehr vornehmen!
- "Mergen": Wenn dann das o.g. Feature auf einem Branch oder Tag fertig ist, möchte man die Änderungen wieder in den "Trunk" (oder auch anderen Branch) zurückführen. Diesen Vorgang nennt man Mergen.
- "Konflikte" Bei einem "Update" / "Merge" kann es passieren, dass es Konflikte gibt, nämlich dann, wenn in einem geänderten Modul auch schon Änderungen im Trunk erfolgten. Welche gelten nun? Diese Konflikte müssen dann händisch aufgelöst werden, sprich da muss man sich dann schon genau ansehen, was denn nun endgültig zurückfließen soll.
Was ich oben geschrieben habe sind so die "Basics", die eigentlich alle Versionskontrollsysteme kennen. Manche benutzen etwas andere Begrifflichkeiten, aber rein semantisch ist das eigentlich jeweils direkt abbildbar.
Unterschied zwischen den gängisten Versionskontrollsystemen "Subversion" (aka SVN) und GIT
- SVN: Bei SVN ist der Workflow bei einem bestehenden Modul wie folgt:
- Man checkt ein projekt aus dem repository aus. Dadurch landet es lokal auf der Harddisk (Kommandozeile "svn checkout <modul>" bzw. "svn update <file>")
- Man nimmt Änderungen vor und checkt diese wieder ein (Kommandozeile "svn commit -m "changed: Dies ist eine ganz tolle Aenderung" <file>")
- GIT: Bei GIT ist das ähnlich, nur dass man bei git quasi auch ein lokales Repo hat!
Bei GIT wird zunächst ein Repository "gecloned" - sprich lokal eine Kopie des REPOSITORIES angelegt. Auf dieser Kopie kann man dann auch lustig comitten ABER diese Commits werden die Anderen nicht sehen, solange man die nicht wie oben comitted. bei GIT heisst das Comitten dann aber PUSHEN. Also GIT arbeitet eigntlich. zweistufig!
- Zunächst "cloned" man das Modul und holt es sich vom EXTERNEN repository, auf das alle Zugreifen. Dadurch wird ein lokales Repo erstellt! (Wichtiger Unterschied zu SVN!)
- Dann nimmt Änderungen vor und checkt diese wieder ein. (git commit <file>) Aber Achtung, dieser Commit checkt nur in das LOKALE Repository ein. Alle Leute die auf das Zentrale repo (hier bei Makerconnect) zugreifen sehen diese Änderungen da noch nicht!
- Ist man dann mit allen lokalen Änderungen fertig, dann muss man die auf das EXTERNE Repository übertragen. Das erfolgt indem man das bei GIT "pushed" (git push). Erst dann werden alle lokalen Änderungen auch in das Externe repository - auf das alle User zugreifen - überführt und auch von den Anderen Usern Nutzbar!
- Ein bereits bestehendes lokales Repository soll ja auch mal wieder mit den Änderungen vom Externen aktualisiert werden,. Das erfolgt eben dann dadurch dass man diese Änderungen "reinzieht" (git pull)
Puh, so viel zur Theorie ;-) Wie sieht das nun in der Praxis aus?
Für Windows existiert ein sehr geniales Projekt namens "Tortoise", welches sowohl SVN (
https://tortoisesvn.net), als auch GIT unterstützt (
https://tortoisegit.org/). Ist das installiert erhält man im Exploreer zus. Funktionen, die u.A. gleich anzeigen, in welchem Stand eine bereits ausgecheckte Datei ist (Wurde verändert, ist Aktuell, ist nicht Teil des Repos etc.)
Außerdem reichert es den Explorer mit einem Eintrag im Kontextmenü an, über den man einen RepoBrowser erreicht, Files (in einer Version) hinzufügt, oder aus dieser löscht oder aber man kann sich die Änderungen zu anderen Versionen bequem anzeigen lassen (Diff), etc.
SVN oder GIT?
Für Dirk (und mich?) stellt sich nun die Frage welche Art von Server wir denn nun installieren? Ich habe auf meinem Linux Server derzeit lediglich einen Subversion Server installiert, könnte aber mal testen, wie man einen GIT Server einrichtet.
GitHub verwendet - wie der Name schon sagt - GIT und ich hätte nichts dagegen, wenn wir das mal versuchen.
@Dirk: Sag mal - unter welchem OS läuft denn der makerconnect? Ist das Linux oder Windows?
Ich werde mal die Tage versuchen einen GIT-Testserver auf meinem lokalen Server (oder meinem Beaglebone) aufzusetzen. Den könnte ich dann mal per dyndns ins Netz bringen und dann verwenden wir den mal zum "Spielen". Wenn das dann klappt, dann versuchen wir das auf Deinem Server. Was hältst Du von dem Vorschlag?
Währenddessen könnten wir uns ja mal überlegen, wie wir das Ganze "filetechnisch" strukturieren. Also was / wie da eiegntlich alles versioniert werden soll. Es war ja zunächst die Rede von Eagle Libs. Wie schaut's mit Eagle Projekten aus, Code-Snippets? Sollen wir die nach Architekturen trennen? Atmel / AVR / ARM etc. ?
Ist der Server erst mal Aufgesetzt ist das aber keine große Sache mehr, man sollte sich aber schon mal Gedanken drüber machen... ;-)
Bin auf Eure Ideen gespannt!
Viele Grüße aus München,
- Peter -
Premium Benutzer