Git und Versionsverwaltung in der mobilen Entwicklung: was es ist, grundlegende Befehle und wie es funktioniert

Versionsverwaltung und Git: Was ist das?

Git ist ein verteiltes Versionskontrollsystem (VCS), das von Linus Torvalds im Jahr 2005 für die Entwicklung des Linux-Kernels erstellt wurde. Im Gegensatz zu zentralisierten Systemen (SVN, CVS) speichert Git eine vollständige Kopie des Projektverlaufs auf jedem Entwicklercomputer. Das bedeutet, dass Sie Commits durchführen, den Verlauf durchsuchen und Branches erstellen können, sogar ohne Internetverbindung.

Git arbeitet mit Snapshots — jeder Commit speichert den Zustand aller Projektdateien zum Zeitpunkt des Speicherns. Wenn sich eine Datei nicht geändert hat, erstellt Git einen Verweis auf die vorherige Version und spart so Platz. Laut GitHub-Analyse (2025) enthält ein durchschnittliches Repository 1.200 Commits und 15 Branches.

Bei IT Sectr verwenden wir Git seit 2017 in allen Projekten. Unsere Erfahrung zeigt, dass eine richtige Git-Konfiguration ab dem ersten Tag dem Team bis zu 30 % Zeit beim Mergen und Lösen von Konflikten spart. Git ist zum De-facto-Standard geworden — es wird von allen modernen IDEs (Android Studio, Xcode, VS Code) und CI/CD-Systemen unterstützt.

# Grundlegende Git-Einrichtung
git config --global user.name "Ihr Name"
git config --global user.email "ihre@email.com"

# Neues Repository erstellen
git init my-project
cd my-project

# Dateien hinzufügen und committen
git add README.md
git commit -m "Initial commit"

# Mit einem entfernten Repository arbeiten
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Der obige Code zeigt die grundlegende Sequenz: Repository initialisieren, erster Commit und Veröffentlichung auf einem entfernten Server. Der Befehl git init erstellt einen versteckten .git-Ordner, der den gesamten Projektverlauf speichert. Jeder git commit erstellt einen Wiederherstellungspunkt, zu dem Sie jederzeit zurückkehren können.

Grundkonzepte: Repository, Branch, Commit

Das Verständnis der drei grundlegenden Konzepte — Repository, Branch und Commit — ist für die Arbeit mit jedem Versionskontrollsystem unerlässlich. Ein Repository ist ein Container für das gesamte Projekt. Ein Commit ist ein gespeicherter Zustand von Dateien. Ein Branch ist eine separate Entwicklungslinie.

Repository kann lokal (auf Ihrem Computer) oder entfernt (auf einem GitHub-, GitLab-Server) sein. Jeder Entwickler klont das entfernte Repository auf seinen Rechner und arbeitet mit einer lokalen Kopie. Änderungen werden per Push (senden) und Pull (holen) synchronisiert. Bei der verteilten Versionskontrolle speichert jeder Entwickler eine vollständige Kopie des Verlaufs.

Branch ist ein Zeiger auf einen der Commits. Branches ermöglichen parallele Entwicklung: Ein Entwickler arbeitet an einer neuen Funktion (Feature-Branch), ein anderer behebt einen Fehler (Hotfix-Branch), ein Dritter bereitet ein Release vor (Release-Branch). Laut GitLab Flow (2025) hat ein durchschnittliches Projekt gleichzeitig 3–5 aktive Branches.

Commit ist eine Änderungseinheit. Jeder Commit enthält einen eindeutigen Hash (SHA-1), eine Nachricht, einen Autor und einen Zeitstempel. Eine gute Praxis ist es, kleine aussagekräftige Commits mit beschreibenden Nachrichten zu machen — das vereinfacht Code Review und das Rückgängigmachen von Änderungen. Die Versionskontrolle durch Commits gibt Ihnen den vollständigen Projektverlauf.

Feature Branch

Feature Branch ist ein temporärer Branch, der von develop oder main für die Entwicklung einer bestimmten Aufgabe erstellt wird. Nach Abschluss der Arbeit wird der Branch per Pull Request zurückgemergt und gelöscht. Diese Praxis ermöglicht es, Änderungen zu isolieren, ohne die Stabilität der Hauptcodebasis zu beeinträchtigen.

Typischer Workflow: Branch feature/add-login erstellen → mehrere Commits machen → Pull Request erstellen → Code Review durchlaufen → in develop mergen. Bei IT Sectr verwenden wir genau diesen Ansatz: Jede Jira-Aufgabe entspricht einem separaten Feature-Branch. Dies vereinfacht die Nachverfolgung von Änderungen und bei Bedarf das Rückgängigmachen.

Rebase vs Merge

Merge erstellt einen Merge-Commit, der zwei Branches zusammenführt. Er bewahrt den vollständigen Verlauf einschließlich paralleler Entwicklungslinien. Rebase überschreibt den Verlauf: Er nimmt Commits von einem Branch und "wendet sie erneut" auf einen anderen an, wodurch ein linearer Verlauf entsteht.

Merge ist besser geeignet für öffentliche Branches und große Teams, bei denen die Chronologie wichtig ist. Rebase ist praktisch für persönliche Feature-Branches vor der Erstellung eines PR — es macht den Verlauf sauberer und verständlicher. Rebase sollte jedoch niemals auf Branches angewendet werden, an denen andere Entwickler arbeiten, da es den Verlauf überschreibt.

# Erstellen und Wechseln zu einem Feature-Branch
git checkout -b feature/add-login main

# Arbeiten im Branch
git add login-screen/
git commit -m "Add login screen layout"

# Rebase auf aktuellen main vor PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push in entferntes Repository
git push origin feature/add-login

Dieses Beispiel zeigt einen typischen Workflow: Erstellen eines Feature-Branches von main, mehrere Commits und Rebase, um vor dem Senden zur Überprüfung einen sauberen linearen Verlauf zu erhalten. Dieser Ansatz minimiert Merge-Konflikte.

Git Flow vs Trunk-Based Development

Git Flow und Trunk-Based Development sind zwei Hauptstrategien der Versionskontrolle, die bestimmen, wie ein Team die Arbeit mit Git organisiert. Die Wahl hängt von der Teamgröße, der Release-Häufigkeit und den Stabilitätsanforderungen ab.

Git Flow ist ein strenges Modell mit mehreren permanenten Branches: main (Release-Code), develop (aktuelle Entwicklung), feature/* (neue Funktionen), release/* (Release-Vorbereitung) und hotfix/* (dringende Korrekturen). Dieses Modell eignet sich gut für Projekte mit klaren Release-Zyklen (z. B. mobile Apps mit Versionen 1.0, 2.0).

Trunk-Based Development ist ein Ansatz mit einem einzigen Hauptbranch (trunk/main), in den alle Entwickler mehrmals täglich Änderungen mergen. Feature-Flags werden verwendet, um unvollständige Funktionen zu verbergen. Dieser Ansatz ist in der Webentwicklung und bei Start-ups beliebt, wo die Liefergeschwindigkeit wichtig ist.

Git Flow

Git Flow, vorgeschlagen von Vincent Driessen im Jahr 2010, bleibt eines der beliebtesten Modelle. Sein Hauptvorteil ist die strikte Trennung des Codes nach Lebenszyklusphasen. Der main-Branch enthält nur Release-Code, develop die aktuelle Entwicklung und Feature-Branches isolieren neue Funktionen voneinander.

Hotfix-Branches werden von main für dringende Korrekturen erstellt und nach dem Merge sowohl in main als auch in develop zurückgemergt. Release-Branches werden von develop erstellt, wenn das Team für ein Release bereit ist. Es werden nur Fehlerkorrekturen und Metadaten (Version, Build) hinzugefügt. Nach dem Release wird der Release-Branch in main und develop gemergt. Laut einer JetBrains-Umfrage (2024) verwenden 37 % der Teams Git Flow. Dieses Versionskontrollmodell bleibt der Standard für Projekte mit festen Releases.

# Git Flow Beispiel: Arbeit an einem Release beginnen
git checkout -b release/1.2.0 develop

# Fehler im Release-Branch beheben
git commit -m "Fix login button crash"

# Release abschließen — in main und develop mergen
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# Release-Branch löschen
git branch -d release/1.2.0

Der Code veranschaulicht das Erstellen eines Release-Branches, dessen Stabilisierung und das Mergen in die Hauptbranches. Das Flag --no-ff garantiert einen Merge-Commit und bewahrt die Information, dass die Änderungen aus dem Release-Branch stammen.

Pull Request und Code Review

Pull Request (PR) ist ein Mechanismus, bei dem ein Entwickler Änderungen aus seinem Branch in den Hauptbranch vorschlägt. PR ist ein Schlüsselelement der Versionskontrolle in der Teamarbeit — es ist nicht nur eine Möglichkeit, Code zu mergen, sondern ein Prozess der Diskussion, Überprüfung und Qualitätssicherung. In GitLab heißt der ähnliche Mechanismus Merge Request (MR), aber das Wesen ist dasselbe: das Team über Änderungen zu informieren und eine Genehmigung zu erhalten.

Ein guter PR sollte klein sein (bis zu 300 Codezeilen), auf eine einzige Aufgabe fokussiert und eine Beschreibung dessen enthalten, was getan wurde und warum. Laut einer Google-Studie (2025) benötigen PRs mit mehr als 400 Zeilen doppelt so lange für die Überprüfung und die Wahrscheinlichkeit, Fehler zu entdecken, sinkt um 30 %. Code Review ist die Überprüfung des Codes durch einen anderen Entwickler vor dem Merge.

Bei IT Sectr praktizieren wir obligatorisches Code Review für jeden PR. Dies verbessert nicht nur die Codequalität, sondern hilft auch, Wissen innerhalb des Teams zu verbreiten. Code Review prüft: ob der Code Architekturprinzipien folgt, ob es Fehler gibt, ob genügend Tests vorhanden sind, ob Variablen richtig benannt sind. Alle Kommentare werden im PR bis zum Merge diskutiert.

Plattformen: GitHub, GitLab, Bitbucket

Git ist ein Protokoll, aber für die Zusammenarbeit benötigen Sie eine Versionskontrollplattform, die eine Weboberfläche, Zugriffsverwaltung, CI/CD und Überprüfungswerkzeuge bietet. Drei Plattformen dominieren den Markt: GitHub, GitLab und Bitbucket.

GitHub ist die größte Plattform mit über 56 Millionen Entwicklern. Es gehört Microsoft und bietet Actions (CI/CD), Pages (Hosting), Discussions und Copilot. Der kostenlose Tarif umfasst unbegrenzte private Repositories für Teams mit bis zu 3 Personen. GitHub ist in der Open-Source-Community beliebt.

GitLab ist eine vollständige DevOps-Plattform mit integrierter CI/CD, Container-Registry und Infrastrukturverwaltung. Im Gegensatz zu GitHub kann GitLab auf Ihrem eigenen Server installiert werden (Self-Managed). Bitbucket von Atlassian ist eng mit Jira und Confluence integriert, was es zur Wahl für Teams macht, die bereits das Atlassian-Ökosystem nutzen.