© S&S Media
Windows Developer
Die populäre Versionskontrolle sicher einsetzen

Git-Grundlagen für .NET-Entwickler

Git hat sich in den letzten Jahren zum Favoriten für die Versionierung von Quellcode entwickelt. Insbesondere die Tatsache, dass Git entwickelt wurde, um die Open-Source-Entwicklung mit vielen Entwicklern optimal zu unterstützen, macht es heute zum populärsten Version Control System (VCS). Doch immer noch fehlen vielen Entwicklern die Grundlagen, um Git sicher und effizient einzusetzen. Neben den Grundlagen von Git zeigt der Artikel, wie Entwickler „fetchen“, „pullen“, „pushen“, „committen“ und souverän mit Tags und Branches umgehen.

Thomas Claudius Huber


Damit Entwickler an einer gemeinsamen Codebasis arbeiten können, wurden zentralisierte Versionskontrollsysteme (VCS) eingeführt – auch CVCS genannt (centralized VCS). Zu diesen Systemen zählen Subversion oder auch das vom Team Foundation Server (TFS) verwendete Team Foundation Version Control (TFVC). Ein solches zentralisiertes VCS hat einen zentralen Server, der die versionierten Dateien enthält. Entwickler checken aus diesem Server aus und speichern Änderungen auf den Server zurück. Jeder kann zentral sehen, wer was gemacht hat, und es lassen sich auch Einstellungen vornehmen, wer überhaupt etwas machen darf. So weit, so gut für eine gute Zusammenarbeit. Allerdings gibt es ein Problem mit den zentralisierten VCS: Entwickler checken nur einen Bruchteil aus – nämlich die Dateien zu einer bestimmten Version. Das führt insbesondere dann oft zu Problemen, wenn der Server nicht da ist. Welcher Entwickler hat während einer Zugfahrt nicht seine Erfahrungen mit TFS gemacht? Lokal ohne Serververbindung kann nicht eingecheckt werden, es kann kein Branch erstellt und nicht geschaut werden, was von anderen Teammitgliedern an einer Datei geändert wurde, da die Historie lokal nicht verfügbar ist usw. In einem Satz: Ohne Server lässt es sich einfach nicht richtig arbeiten. Neben diesem Problem haben zentralisierte VCS einen weiteren Schwachpunkt: den zentralen Server. Jede IT-Abteilung macht natürlich ihre seriösen Backups. Man stelle sich nur vor, das Backup hat nicht richtig funktioniert und die Festplatte des Servers hat ihre besten Zeiten hinter sich. Dann sind die Daten weg.

Genau an diesen Problempunkten von zentralisierten VCS setzen verteilte VCS an – auch als distributed VCS oder kurz DVCS bezeichnet. Zu den verteilten VCS gehört Git. Bei einem verteilten VCS checken Entwickler nicht nur die Dateien zu einer bestimmten Version aus, es wird vielmehr das komplette Repository lokal gespiegelt. Somit hat jeder Entwickler lokal ein eigenes, komplettes Repository, das er mit einem beliebigen anderen Repository abgleichen kann. Auf diese Weise kann man lokal committen, die Historie anschauen, Branches erstellen und alles andere tun, was man sich von einem VCS wünscht, ohne dass der Server verfügbar sein muss. Zudem ist jedes lokale Repository ein gültiges Backup für den Server, da es eine Spiegelung des Server-Repositories ist.

Aber es kommt noch besser: Ein lokales Repository lässt sich mit einem oder auch mehreren beliebigen anderen Repositories abgleichen. Somit k...

Windows Developer
Die populäre Versionskontrolle sicher einsetzen

Git-Grundlagen für .NET-Entwickler

Git hat sich in den letzten Jahren zum Favoriten für die Versionierung von Quellcode entwickelt. Insbesondere die Tatsache, dass Git entwickelt wurde, um die Open-Source-Entwicklung mit vielen Entwicklern optimal zu unterstützen, macht es heute zum populärsten Version Control System (VCS). Doch immer noch fehlen vielen Entwicklern die Grundlagen, um Git sicher und effizient einzusetzen. Neben den Grundlagen von Git zeigt der Artikel, wie Entwickler „fetchen“, „pullen“, „pushen“, „committen“ und souverän mit Tags und Branches umgehen.

Thomas Claudius Huber


Damit Entwickler an einer gemeinsamen Codebasis arbeiten können, wurden zentralisierte Versionskontrollsysteme (VCS) eingeführt – auch CVCS genannt (centralized VCS). Zu diesen Systemen zählen Subversion oder auch das vom Team Foundation Server (TFS) verwendete Team Foundation Version Control (TFVC). Ein solches zentralisiertes VCS hat einen zentralen Server, der die versionierten Dateien enthält. Entwickler checken aus diesem Server aus und speichern Änderungen auf den Server zurück. Jeder kann zentral sehen, wer was gemacht hat, und es lassen sich auch Einstellungen vornehmen, wer überhaupt etwas machen darf. So weit, so gut für eine gute Zusammenarbeit. Allerdings gibt es ein Problem mit den zentralisierten VCS: Entwickler checken nur einen Bruchteil aus – nämlich die Dateien zu einer bestimmten Version. Das führt insbesondere dann oft zu Problemen, wenn der Server nicht da ist. Welcher Entwickler hat während einer Zugfahrt nicht seine Erfahrungen mit TFS gemacht? Lokal ohne Serververbindung kann nicht eingecheckt werden, es kann kein Branch erstellt und nicht geschaut werden, was von anderen Teammitgliedern an einer Datei geändert wurde, da die Historie lokal nicht verfügbar ist usw. In einem Satz: Ohne Server lässt es sich einfach nicht richtig arbeiten. Neben diesem Problem haben zentralisierte VCS einen weiteren Schwachpunkt: den zentralen Server. Jede IT-Abteilung macht natürlich ihre seriösen Backups. Man stelle sich nur vor, das Backup hat nicht richtig funktioniert und die Festplatte des Servers hat ihre besten Zeiten hinter sich. Dann sind die Daten weg.

Genau an diesen Problempunkten von zentralisierten VCS setzen verteilte VCS an – auch als distributed VCS oder kurz DVCS bezeichnet. Zu den verteilten VCS gehört Git. Bei einem verteilten VCS checken Entwickler nicht nur die Dateien zu einer bestimmten Version aus, es wird vielmehr das komplette Repository lokal gespiegelt. Somit hat jeder Entwickler lokal ein eigenes, komplettes Repository, das er mit einem beliebigen anderen Repository abgleichen kann. Auf diese Weise kann man lokal committen, die Historie anschauen, Branches erstellen und alles andere tun, was man sich von einem VCS wünscht, ohne dass der Server verfügbar sein muss. Zudem ist jedes lokale Repository ein gültiges Backup für den Server, da es eine Spiegelung des Server-Repositories ist.

Aber es kommt noch besser: Ein lokales Repository lässt sich mit einem oder auch mehreren beliebigen anderen Repositories abgleichen. Somit k...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang