Lernpfad:Einführung in Git/1 - Versionsgeschichte

Jneug am 3. November 2022 um 08:38 Uhr

2022-11-03T08:38:14Z

← Nächstältere Version		Version vom 3. November 2022, 10:38 Uhr
Zeile 17:		Zeile 17:
	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.		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 Torvalds\|Linus Torvalds]] entwickelt, um den Open-Source Kernel von Linus zu verwalten. Git ist mittlerweile eines der am weitesten verbreiteten Versionsverwaltungssysteme, die heute im Einsatz sind.

	Git arbeitet - anders als die meisten Systeme - grundsätzlich [[wikipedia:Dezentralität\|''dezentral'']], wobei wir uns in diesem Lernpfad zunächst auf ein zentrales Vorgehen konzentrieren wollen.		Git arbeitet - anders als die meisten Systeme - grundsätzlich [[wikipedia:Dezentralität\|''dezentral'']], wobei wir uns in diesem Lernpfad zunächst auf ein zentrales Vorgehen konzentrieren wollen.

Ngb am 17. August 2022 um 20:04 Uhr

2022-08-17T20:04:09Z

← Nächstältere Version		Version vom 17. August 2022, 22:04 Uhr
Zeile 33:		Zeile 33:
	## Änderungen zurücksenden (''push'').		## Änderungen zurücksenden (''push'').

	Ein ''~~Respository~~'' bezeichnet einen Ordner mit verschiedenen Dateien und Verzeichnissen, die mit Git verwaltet werden. In unserem Fall könnte das ein {{BlueJ}}-Projekt sein, mit den Quelltexten als <code>.java</code> Dateien.		Ein ''Repositories'' bezeichnet einen Ordner mit verschiedenen Dateien und Verzeichnissen, die mit Git verwaltet werden. In unserem Fall könnte das ein {{BlueJ}}-Projekt sein, mit den Quelltexten als <code>.java</code> Dateien.

	[[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.

Jneug am 12. Februar 2022 um 16:13 Uhr

2022-02-12T16:13:13Z

← Nächstältere Version		Version vom 12. Februar 2022, 18:13 Uhr
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.

Jneug: /* Grundbegriffe */

2021-08-29T09:24:20Z

Grundbegriffe

← Nächstältere Version		Version vom 29. August 2021, 11:24 Uhr
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 ~~nurt~~ 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 da 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.

Jneug: /* Versionsverwaltungssysteme */

2021-08-29T09:22:48Z

Versionsverwaltungssysteme

← Nächstältere Version		Version vom 29. August 2021, 11:22 Uhr
Zeile 19:		Zeile 19:
	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.

	Git arbeitet - anders als die meisten Systeme - grundsätzlich ''dezentral'', wobei wir uns in diesem Lernpfad zunächst auf ein zentrales Vorgehen konzentrieren wollen.		Git arbeitet - anders als die meisten Systeme - grundsätzlich [[wikipedia:Dezentralität\|''dezentral'']], wobei wir uns in diesem Lernpfad zunächst auf ein zentrales Vorgehen konzentrieren wollen.

	== Grundbegriffe ==		== Grundbegriffe ==

Jneug: /* Grundbegriffe */

2021-08-29T09:22:08Z

Grundbegriffe

← Nächstältere Version		Version vom 29. August 2021, 11:22 Uhr
Zeile 37:		Zeile 37:
	[[Datei:Git Struktur.png\|center]]		[[Datei:Git Struktur.png\|center]]

	Beim ~~Anelgen~~ 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 nurt 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 da 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 nurt 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 da sein, muss zunächst ein weiterer ''pull'' durchgeführt werden, bevor schließlich die Änderungen ''gepushed'' werden können.

Jneug: /* Grundbegriffe */

2021-08-29T09:21:39Z

Grundbegriffe

← Nächstältere Version		Version vom 29. August 2021, 11:21 Uhr
Zeile 33:		Zeile 33:
	## Änderungen zurücksenden (''push'').		## Änderungen zurücksenden (''push'').

	Ein ''Respository'' bezeichnet einen Ordner mit verschiedenen Dateien und Verzeichnissen, ~~das~~ mit Git verwaltet ~~wird~~. In unserem Fall könnte das ein BlueJ-Projekt sein, mit den Quelltexten als <code>.java</code> Dateien.		Ein ''Respository'' bezeichnet einen Ordner mit verschiedenen Dateien und Verzeichnissen, die mit Git verwaltet werden. In unserem Fall könnte das ein {{BlueJ}}-Projekt sein, mit den Quelltexten als <code>.java</code> Dateien.

	[[Datei:Git Struktur.png\|center]]		[[Datei:Git Struktur.png\|center]]

	Beim Anelgen 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 nurt 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 da sein, muss zunächst ein weiterer ''pull'' durchgeführt werden, bevor schließlich die Änderungen ''gepushed'' werden können.		Beim Anelgen 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 nurt 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 da sein, muss zunächst ein weiterer ''pull'' durchgeführt werden, bevor schließlich die Änderungen ''gepushed'' werden können.

Jneug am 7. September 2020 um 12:36 Uhr

2020-09-07T12:36:12Z

← Nächstältere Version		Version vom 7. September 2020, 14:36 Uhr
Zeile 1:		Zeile 1:
	{{NNavigation~~}}{{Inhalt/NÜbersicht~~}}		{{NNavigation}}

	== Das Problem ==		== Das Problem ==

Jneug am 7. September 2020 um 12:33 Uhr

2020-09-07T12:33:31Z

← Nächstältere Version		Version vom 7. September 2020, 14:33 Uhr
Zeile 1:		Zeile 1:
	{{NNavigation}}		{{NNavigation}}{{Inhalt/NÜbersicht}}

	== Das Problem ==		== Das Problem ==

Jneug: /* Grundbegriffe */

2020-08-25T10:33:37Z

Grundbegriffe

← Nächstältere Version		Version vom 25. August 2020, 12:33 Uhr
Zeile 37:		Zeile 37:
	[[Datei:Git Struktur.png\|center]]		[[Datei:Git Struktur.png\|center]]

	Beim Anelgen 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 (''~~commited~~''). Diese Änderungen liegen zunächst nurt 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 da sein, muss zunächst ein weiterer ''pull'' durchgeführt werden, bevor schließlich die Änderungen ''gepushed'' werden können.		Beim Anelgen 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 nurt 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 da sein, muss zunächst ein weiterer ''pull'' durchgeführt werden, bevor schließlich die Änderungen ''gepushed'' werden können.