Lernpfad:Einführung in Git/1: Unterschied zwischen den Versionen

keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 7: Zeile 7:
Je nach Größe des Projekts können von einigen wenigen bis zu hunderten Entwicklern an einer Software arbeiten. Das erfordert klare Absprachen.
Je nach Größe des Projekts können von einigen wenigen bis zu hunderten Entwicklern an einer Software arbeiten. Das erfordert klare Absprachen.


Wenn so viele Personen - die manchmal über die ganze Welt verteilt sind - an derselben Software arbeiten, kommt es schnell zu Problemen. Es wird aus Versehen ein Fehler eingebaut; zwei Mitarbeiter arbeiten an demselben Teil des Programms und ändern gleichzeitig dieselben Dateien; mehrere Programmierer haben Teile implementiert, die nun zusammengeführt werden müsen; usw.
Wenn so viele Personen - die manchmal über die ganze Welt verteilt sind - an derselben Software arbeiten, kommt es schnell zu Problemen. Es wird aus Versehen ein Fehler eingebaut; zwei Mitarbeiter arbeiten an demselben Teil des Programms und ändern gleichzeitig dieselben Dateien; mehrere Programmierer haben Teile implementiert, die nun zusammengeführt werden müssen; usw.


Schnell hat man erkannt, dass man dafür eine Lösung braucht und die ersten Versionsverwaltungssysteme entwickelt.
Schnell hat man erkannt, dass man dafür eine Lösung braucht und die ersten Versionsverwaltungssysteme entwickelt.
Zeile 15: Zeile 15:
[[Datei:Git-logo.svg|240px|right|Git-Logo]] Versionsverwaltungssysteme erlauben es einem Team am selben Code zu arbeiten, ohne miteinander in Konflikt zu kommen. Sollte es dennoch zu einem Konflikt kommen, helfen diese Systeme dabei, ihn zu beheben.
[[Datei:Git-logo.svg|240px|right|Git-Logo]] Versionsverwaltungssysteme erlauben es einem Team am selben Code zu arbeiten, ohne miteinander in Konflikt zu kommen. Sollte es dennoch zu einem Konflikt kommen, helfen diese Systeme dabei, ihn zu beheben.


In der Regel gibt es dazu einen zentralen Server, auf dem der komplette Quelltext gespeichert ist. Ein Mitarbeiter lädt sich dann den aktuellen Quelltext auf seine Maschine, nimmt einige Änderungen vor und lädt den neuen Quelltext zurück, so dass ihn die anderen Mitarbeiter nutzen können. Schleicht sich dabei ein Fehler ein, kann der Programmcode zu jedem beliebigen Zeitpunkt der Entwicklung zurückgesetzt werden. Die Änderungen können also rückgängig gemacht werden.
In der Regel gibt es dazu einen zentralen Server, auf dem der komplette Quelltext gespeichert ist. Ein Mitarbeiter lädt sich dann den aktuellen Quelltext auf seine Maschine, nimmt einige Änderungen vor und lädt den neuen Quelltext zurück, sodass ihn die anderen Mitarbeiter nutzen können. Schleicht sich dabei ein Fehler ein, kann der Programmcode zu jedem beliebigen Zeitpunkt der Entwicklung zurückgesetzt werden. Die Änderungen können also rückgängig gemacht werden.


Das Versionsverwaltungssystem '''Git''' wurde vom Linux-Erfinder [[wikipedia:Linus Tovals|Linus Tovals]] entwickelt, um den Open-Source Kernel von Linus zu verwalten. Git ist mittlerweile eines der am weitesten verbreiteten Versionsverwaltungssysteme, die heute im Einsatz sind.
Das Versionsverwaltungssystem '''Git''' wurde vom Linux-Erfinder [[wikipedia:Linus Tovals|Linus Tovals]] entwickelt, um den Open-Source Kernel von Linus zu verwalten. Git ist mittlerweile eines der am weitesten verbreiteten Versionsverwaltungssysteme, die heute im Einsatz sind.
Zeile 37: Zeile 37:
[[Datei:Git Struktur.png|center]]
[[Datei:Git Struktur.png|center]]


Beim Anlegen eines Repositories kann dieses entweder leer initialisiert (''init''), oder als Kopie (''fork'') eines bestehenden erzeugt werden. Sobald das Repository auf einem zentralen Server liegt kann es von dort mit dem ''clone'' Befehl auf den eigenen Arbeitsrechner heruntergeladen werden. Dies muss nur einmal passieren. Danach werden mit dem ''pull'' Befehl nur noch die neusten Änderungen geladen. Dann wird zunächst auf dem eigenen Rechner programmiert. Zwischendurch werden die Änderungen in das lokal geklonte Repository eingespeichert (''commit''). Diese Änderungen liegen zunächst nur auf dem eigenen Rechner. Erst wenn alle Änderungen mit dem ''push'' Befehl auf den zentralen Rechner geladen werden, können die anderen Programmierer auf den Code zugreifen. Bevor man dies tut, sollte aber zuerst mit dem ''fetch'' Befehl geprüft werden, ob seit dem letzten ''pull'' neue Änderungen (von anderen Programmierern) vorgenommen wurden, da man sonst vielleicht einen Konflikt erzeugt. Sollten Änderungen vorhanden sein, muss zunächst ein weiterer ''pull'' durchgeführt werden, bevor schließlich die Änderungen ''gepushed'' werden können.
Beim Anlegen eines Repositories kann dieses entweder leer initialisiert (''init''), oder als Kopie (''fork'') eines bestehenden erzeugt werden. Sobald das Repository auf einem zentralen Server liegt, kann es von dort mit dem ''clone'' Befehl auf den eigenen Arbeitsrechner heruntergeladen werden. Dies muss nur einmal passieren. Danach werden mit dem ''pull'' Befehl nur noch die neusten Änderungen geladen. Dann wird zunächst auf dem eigenen Rechner programmiert. Zwischendurch werden die Änderungen in das lokal geklonte Repository eingespeichert (''commit''). Diese Änderungen liegen zunächst nur auf dem eigenen Rechner. Erst wenn alle Änderungen mit dem ''push'' Befehl auf den zentralen Rechner geladen werden, können die anderen Programmierer auf den Code zugreifen. Bevor man dies tut, sollte aber zuerst mit dem ''fetch'' Befehl geprüft werden, ob seit dem letzten ''pull'' neue Änderungen (von anderen Programmierern) vorgenommen wurden, da man sonst vielleicht einen Konflikt erzeugt. Sollten Änderungen vorhanden sein, muss zunächst ein weiterer ''pull'' durchgeführt werden, bevor schließlich die Änderungen ''gepushed'' werden können.
8.581

Bearbeitungen