Ohne GIT geht es nit!
Git gehört zum Programmierer*innen-Alltag dazu und ist ein hilfreiches Tool, das einfach zu erlernen ist.
In diesem Blogartikel erklären wir euch genauer, wie Git verwendet wird.
Einen kleinen Einstieg gab es schon in einem früheren Blogbeitrag zum Thema Git: https://wp-entwickler.at/3226/dir-faellt-zu-git-nur-igittigitt-ein-das-muss-nicht-sein-git-ist-easy-und-hilfreich/
Wie funktioniert die Arbeit mit Git?
Alle Daten befinden sich an einer zentralen Stelle. Dem Repository (Repo). Das kann irgend ein Server im Internet sein, aber auch ein Ort im lokalen Netzwerk.
Jedes Git-Repository verfügt über den gesamten Datenstand. Um damit zu arbeiten, muss es jedoch erst auf einen Rechner heruntergeladen werden. Diesen Vorgang nennt man klonen. Zusätzlich zu den Dateien enthält das Repository auch die ganze Geschichte, wer, was, in welcher Datei verändert, gelöscht oder hinzugefügt hat.
Wenn ich eine Datei ändere, muss diese Datei auch wieder ins Repository hochgeladen werden. Dieser Vorgang ist in zwei Teile geteilt. Zuerst wählen wir die Dateien aus, die wir hochladen wollen und erläutern, was unsere Änderungen bewirken. Das geschieht im sogenannten Commit. Im zweiten Teil machen wir unsere Änderungen allen anderen zugänglich, indem wir unseren Commit ins Repo hochladen. Diesen Vorgang nennt man push.
Da es keine automatische Synchronisation gibt, müssen wir uns selber um den Stand unserer lokalen Daten kümmern. Daher empfiehlt es sich zu Beginn der Arbeit und vor jedem push den lokalen Stand mit dem des Repos abzugleichen. Im sogenannten pull erfragen wir, ob sich seit unserem letzten push etwas getan hat und wenn ja, soll unser lokaler Stand aktualisiert werden.
Je mehr Personen an einem Projekt beteiligt sind, desto leichter kann es vorkommen, dass man parallel in der selben Datei arbeitet. Hier wird es zum ersten Mal etwas komplizierter, wenn es zu Konflikten zwischen der Arbeit eines Kollegen und meiner kommt. Es kommt zum gefürchteten Merge! D.h. wir müssen im schlimmsten Fall händisch unsere Änderungen mit denen unseres Kollegen abgleichen und entscheiden, was die korrekt Version der Datei ist, die letztlich im Repository zu finden sein wird.
Wenn wir Glück haben, wurden aber nur Zeilen oder Dateien geändert, die unsere Änderungen gar nicht betreffen. In so einem Fall geschieht der Merge meist automatisch, ohne eigenes Eingreifen. Kleiner Tipp: Rebase! Wenn wir unseren pull mit dem Parameter –rebase absetzen, lösen wir unsere Arbeit kurz heraus und git spielt uns die Änderungen ein. Ganz ohne (automatischen) Merge. Danach können wir ganz einfach weiterarbeiten.
Je nach Komplexität des Projekts kann so ein Merge aber schon mal länger dauern. Daher ist es ratsam, Commits eher klein und thematisch abgegrenzt zu halten.
Für die meisten kleineren Projekte deckt das ziemlich gut ab, wie die Arbeit mit Git ausschaut. Doch Git kann noch sehr viel mehr!
Erweiterter Workflow mit Branches und Pull-Request
Sobald es notwendig wird, die Arbeit an einem Projekt in eigene Versionen zu unterteilen, müssen wir uns den Branches widmen.
Eines Vorweg: Bei Git gibt es immer mindestens einen Branch. Das ist der Hauptbranch. Auch master/main Branch genannt. Im letzten Abschnitt haben wir somit immer im Hauptbranch gearbeitet.
Neben diesem Hauptbranch können wir unzählige weitere Branches erstellen. Ich kann sowohl vom Hauptbranch als auch von anderen Branches ableiten. Jeder dieser neuen Branches ist eine exakte Kopie vom Zeitpunkt der Erstellung. So ein Branch ist nützlich, um an neuen Features zu arbeiten oder um Code zu testen, ohne den Hauptzweig zu beeinflussen.
Wir müssen dabei nicht jeden Branch zwingend ins Repo hochladen. So ein Branch kann auch nur lokal verwendet werden, um bestimmte Codestellen zu testen. Allerdings würde ich davon abraten. Im besten Fall profitieren alle davon.
Die meisten IDEs machen es einem recht leicht, einen neuen Branch zu erstellen oder zu einem anderen Branch zu wechseln. Das Zauberwort hierfür heißt übrigens checkout.
Diesen Checkout-Prozess benötigen wir übrigens auch, wenn wir den Stand unseres lokalen Repositories auf einen älteren Commit ändern wollen. Weil wir die gesamte Geschichte des Repos kennen, können wir uns auf dieser Achse frei bewegen und uns den konkreten Stand des Projekts von vor Monaten/Jahren ansehen.
An steigender Komplexität eines Projekts leidet auch oft die Übersichtlichkeit. Irgendwann gelangt man an einem Punkt, wo nicht mehr jedes Teammitglied den gesamten Code überblicken kann. Um sicherzustellen, dass der Code weiterhin von zumindest zwei Personen durchgesehen wird, kann man mit Pull-Requests arbeiten. Hier wird in einem eigenen Branch z.B. an einem neuen Feature gearbeitet. Sobald die Arbeit daran erledigt ist, erstellt man einen Pull-Request für den Hauptbranch. Eine weitere Person geht den Pull-Request durch und kann diesen dann durchwinken (aka mergen) oder zurückweisen und z.B. um Anpassungen bitten.
Diese Strategie ist besonders bei öffentlichen Repositories zu empfehlen, wenn wir nicht alle Personen kennen, die daran arbeiten, oder ihnen einfach nicht genug vertrauen.
Fazit
Git macht das Arbeiten im Team effizient und sorgt nur selten für Kopfschmerzen.
Durch die Tatsache, dass ich jederzeit eine Kopie vom gesamten Code lokal am PC habe, bin ich flexibler bei der Einteilung meiner Arbeit. Ich kann auch zeitgleich mit Kollegen an der selben Datei arbeiten, ohne dass mir mein Fortschritt überschrieben wird. Lediglich beim Zusammenführen der Ergebnisse ist etwas Obacht geboten!
Durch das Branching bin ich in der Lage, einfacher an Features zu arbeiten oder am Code herum zu experimentieren, ohne dass es direkten Einfluss auf den Hauptzweig der Entwicklung hat. Ich muss mich nicht fürchten, etwas kaputt zu machen, weil ich jederzeit zu einem älteren Commit wechseln und wieder sauber von vorne starten kann.