Grundlage und Best Practices für die Entwicklung mit Git

Forks und Branches

In der Softwareentwicklung erstellt ein Fork (Gabel) eine neue, unabhängige Kopie des Quellcodebaums. Manchmal benötigen Entwickler eine völlig neue und eigenständige Kopie der Daten. Wenn sie ein Git-Projekt abspalten, wird es zu einer eigenen separaten Instanz, was bedeutet, dass es das ursprüngliche Projekt nicht verändert. Open-Source-Entwickler erstellen oft Forks, wenn sie eine bestehende Codebasis für ein neues Projekt nutzen wollen.

Wenn ein Entwickler git add, git commit und andere Befehle verwendet, muss er standardmäßig eine lokale Kopie anlegen. Bei der Zusammenführung (Merge) übergeben sie es in die zentralisierte Master-Version des Codes mit git push origin master.

Ein Zusammenführungskonflikt tritt auf, wenn zwei Entwickler die gleiche Datei ändern und unterschiedliche Versionen des Codes haben. Jeder Entwickler kann an dieser Stelle git pull verwenden – nicht zu verwechseln mit einem Pull Request –, um Änderungen in seine lokalen Kopien herunterzuladen.

Programmierer können die Option git rebase nutzen, um alle Änderungen zusammen in einer Entwicklerkopie zu synchronisieren, was diese Kopie zum Master macht, nachdem sie die Änderungen hochgeladen und integriert haben.

Häufiger verwenden Entwickler Branches (Zweige), wenn sie an wesentlichen Änderungen arbeiten. So kann zum Beispiel ein Team unabhängig von laufenden Bugfixes und anderen Projekten an einer neuen Funktion arbeiten.

Zweige sind unabhängig von Änderungen am Hauptstamm, auch Master genannt. Entwickler können mit Git unabhängig voneinander an diesen Zweigen arbeiten und diese zu einem späteren Zeitpunkt wieder in das Master einbinden. Diese Struktur ermöglicht es, mehrere unabhängige Projekte zu starten, ohne die täglichen Codeänderungen zu beeinflussen.

Entwickler können ihre Änderungen dann über einen Merge Request, der im Wesentlichen ein Peer Review des Updates ist, wieder einreichen. Nach der Genehmigung zieht das Team den Merge Request zurück in den Hauptstamm.

Einige Konflikte können zwischen den verschiedenen Zweigen und Stämmen auftreten, aber sie sind in der Regel leicht zu lösen. Zweige sind logisch vom Hauptstamm getrennt, aber das kann ein Pull Request eines anderen Entwicklers vor der Genehmigung nicht verhindern.

Git lebt von Teamwork

Bevor IT-Teams mit Git arbeiten, müssen sie eine Reihe von Standards verstehen und sich darauf einigen, da Entwickler Git auf vielfältige Weise nutzen – oder unsachgemäß verwenden können. Ohne vereinbarte Best Practices kann das Team Daten verlieren, wenn nicht sogar in Chaos versinken, wenn es versucht, nicht genehmigte Änderungen vorzunehmen. Gitflow ist ein Satz von Best Practices, die ein Unternehmen in verteilten Umgebungen einsetzen können.

Insbesondere das Management muss einige Entscheidungen über das Versionskontrollsystem treffen. Ein Team kann zwischen extern gehosteten oder selbst gehosteten Versionen von Git wählen, die jeweils unterschiedliche Vor- und Nachteile haben. Für die meisten Benutzer bietet das gehostete Git alle notwendigen Ressourcen.

Wenn es um die Sicherheit geht, sollten Administratoren die Konten mit Zwei-Faktor-Authentifizierung schützen und den Zugriff auf das Repository mit Active Directory verwalten, das GitHub bereits in begrenztem Umfang unterstützt.