Git und Versionsverwaltung — so arbeiten Entwickler gemeinsam an Code

Schreiben mehrere Personen Code am selben Projekt ohne ein gemeinsames System, entsteht schnell Chaos: wer hat die neueste Version, was wurde wann geändert, und wie findet man zu einer Version zurück, die funktionierte, wenn eine neue Änderung einen Fehler einführt? Die Versionsverwaltung löst genau dieses Problem, indem sie die gesamte Historie der Änderungen speichert, sodass nie wirklich Arbeit verloren geht.

Git ist ein verteiltes Versionsverwaltungssystem, was bedeutet, dass die Kopie jedes Entwicklers die gesamte Historie des Projekts enthält, nicht nur die neuesten Dateien. Das macht es möglich, auch ohne Verbindung zu einem zentralen Server zu arbeiten und die Historie einzusehen, und es macht das System robust — geht der zentrale Server verloren, existiert die Geschichte des Projekts noch bei allen, die es geholt haben.

• 01Commit: eine gespeicherte Momentaufnahme des Projektzustands mit einer beschreibenden Nachricht darüber, was geändert wurde
• 02Branch (Zweig): eine eigenständige Entwicklungslinie, auf der man arbeiten kann, ohne den Hauptzweig zu beeinflussen
• 03Merge: die Änderungen zweier Branches wieder zusammenführen
• 04Repository: das Projekt selbst mit seiner gesamten Historie
• 05Remote: eine zentrale, geteilte Ausgabe des Repositorys, die zum Beispiel bei einem Dienst gehostet wird, von dem alle holen und an den alle senden können

In der Praxis arbeitet man selten direkt am Hauptzweig. Stattdessen legt man einen neuen Branch für eine bestimmte Aufgabe oder Korrektur an, arbeitet dort fertig und bittet danach darum, die Änderungen durchsehen und in den Hauptzweig einfließen zu lassen — das nennt man einen Pull Request oder Merge Request. Das gibt Kollegen die Möglichkeit, durchzulesen und zu kommentieren, bevor der Code Teil dessen wird, worauf alle anderen weiterbauen — eine Form der Qualitätskontrolle, die der ähnelt, die eine Lehrkraft einer Arbeit vor der Genehmigung geben würde.

Haben zwei Personen dieselbe Zeile in derselben Datei auf jeweils einem eigenen Branch geändert, kann Git nicht automatisch entscheiden, welche Änderung gewinnen soll — das nennt man einen Merge-Konflikt. Das System markiert, wo die beiden Versionen sich widersprechen, und eine Person muss manuell wählen, wie sie zusammengeführt werden. Häufige, kleinere Commits und gute Kommunikation im Team verringern, wie oft das passiert.

“Git merkt sich alles, was du es merken lässt. Der Sinn ist nicht, Fehler zu vermeiden, sondern immer zu dem Zustand vor dem Fehler zurückfinden zu können.”

— Erfahrungsregel aus der Softwareentwicklung