Unser Team arbeitet seit Jahren mit Git. Lohnt sich das trotzdem?

Gerade dann. Die meisten Teams beherrschen einen eingespielten Pfad und weichen ihm nie ab – bis ein Merge schiefgeht oder eine Historie unbrauchbar wird. Wir arbeiten mit erfahrenen Teams vor allem an Branching-Strategie, Review-Abläufen und den Situationen, die im Alltag Angst machen: interaktives Rebase, verlorene Commits, `bisect`.

Welche Plattform wird verwendet – GitHub, GitLab, etwas anderes?

Die Konzepte sind plattformunabhängig, die Übungen richten wir nach Ihrem Setup aus. Ob GitHub, GitLab, Forgejo/Gitea oder eine andere Oberfläche: Wir arbeiten mit dem, was Ihr Team tatsächlich benutzt, damit die Abläufe direkt übertragbar sind.

Was bedeutet „saubere Historie“ konkret, und ist das nicht Geschmackssache?

Teilweise ja – deshalb erarbeiten wir keine Doktrin, sondern die Konsequenzen. Eine Historie ist dann gut, wenn sie die Fragen beantwortet, die Sie ihr später stellen: Wann kam dieser Fehler rein, was gehörte zu dieser Änderung, was lässt sich gefahrlos zurücknehmen. Welche Konventionen das erreichen, entscheidet Ihr Team – wir zeigen die Optionen samt Preis.

Ist das eine reine Git-Schulung oder geht es auch um den Entwicklungsprozess?

Beides, weil das eine ohne das andere wenig taugt. Branching-Strategie, Review-Kultur und CI-Anbindung hängen zusammen: Eine Strategie, die nicht zu Ihrem Release-Rhythmus passt, wird umgangen, egal wie gut sie auf dem Papier aussieht.

Git-Schulung: Versionsverwaltung, die im Team trägt

Fast jedes Team benutzt Git. Deutlich weniger Teams benutzen es souverän. Zwei Tage, die den Unterschied ausmachen: ein belastbares Modell davon, was Git tatsächlich tut – und Abläufe, die auch dann noch funktionieren, wenn es eng wird.

Niveau: Einsteiger – Fortgeschritten
Dauer: 2 Tage
Formate: Inhouse · Remote

Projekt anfragen Alle Schulungen

Schwerpunkte

Branching-Strategien im Team
Rebase, Merge & saubere Historie
Code Review & Pull Requests
Konflikte, Rettung & Bisect

Für wen diese Schulung gedacht ist

Für Entwicklungsteams, die Git täglich benutzen und trotzdem regelmäßig an dieselben Stellen stoßen: ein Merge, den niemand auflösen möchte; eine Historie, in der nicht mehr nachvollziehbar ist, warum eine Zeile so aussieht, wie sie aussieht; ein Branching-Modell, das aus einem Blogartikel übernommen wurde und nicht recht zum eigenen Release-Rhythmus passt.

Ebenso für gemischte Teams, in denen einige Kollegen sehr sicher unterwegs sind und andere sich auf drei auswendig gelernte Kommandos beschränken – ein Gefälle, das in Code-Reviews und bei Konflikten teuer wird.

Inhalte

Tag 1 – Das Modell und der Alltag. Was Git tatsächlich speichert: Objekte, Referenzen, der Index. Dieses Modell ist der Grund, warum die meisten Verwirrungen entstehen – wer es einmal sauber im Kopf hat, versteht auch ungewohnte Kommandos. Darauf aufbauend: Branching-Strategien im Vergleich (trunk-basiert, Release-Branches, Feature-Branches), ihre Voraussetzungen und ihre Kosten. Wir ordnen Ihr aktuelles Modell ein und arbeiten heraus, woran es reibt.

Tag 2 – Historie, Review und Notfälle. Rebase gegen Merge, und wann welches Vorgehen die bessere Antwort ist. Interaktives Rebase zum Aufräumen vor dem Review. Commits, die als Einheit Sinn ergeben, und Nachrichten, die in einem Jahr noch etwas erklären. Code-Review als Ablauf statt als Formalie, Anbindung an die CI. Zum Abschluss die Rettungsübungen: verlorene Commits über das Reflog zurückholen, bisect zum Eingrenzen eines eingeschleppten Fehlers, Konflikte in großen Merges systematisch auflösen.

Was Ihr Team danach kann

Eine Branching-Strategie bewusst wählen und begründen, statt sie zu erben. Eine Änderung so aufbereiten, dass ein Review schnell und gründlich möglich ist. Einen Fehler mit bisect in wenigen Minuten auf einen Commit eingrenzen. Und – der unterschätzte Punkt – in einer verfahrenen Situation ruhig bleiben, weil klar ist, dass in Git praktisch nichts wirklich verloren geht.

Voraussetzungen

Praktische Erfahrung mit Git im Alltag: committen, pushen, in Branches arbeiten. Wir setzen keine Kenntnis der inneren Struktur voraus – die erarbeiten wir gemeinsam.

Format und Ablauf

Zwei Tage, inhouse oder remote. Die Übungen laufen in Repositories, die wir gezielt in die Situationen bringen, um die es geht – Konflikte und verkorkste Historien lassen sich schlecht besprechen, wenn man sie nicht vor sich hat.

Auf Wunsch schauen wir am zweiten Tag auf Ihr eigenes Repository und Ihren tatsächlichen Ablauf. Das ist der Teil, aus dem Teams erfahrungsgemäß am meisten mitnehmen – setzt aber voraus, dass Sie uns Einblick geben möchten. Ohne diesen Einblick arbeiten wir mit realistisch nachgebauten Beispielen.

Häufige Fragen

Unser Team arbeitet seit Jahren mit Git. Lohnt sich das trotzdem?: Gerade dann. Die meisten Teams beherrschen einen eingespielten Pfad und weichen ihm nie ab – bis ein Merge schiefgeht oder eine Historie unbrauchbar wird. Wir arbeiten mit erfahrenen Teams vor allem an Branching-Strategie, Review-Abläufen und den Situationen, die im Alltag Angst machen: interaktives Rebase, verlorene Commits, `bisect`.
Welche Plattform wird verwendet – GitHub, GitLab, etwas anderes?: Die Konzepte sind plattformunabhängig, die Übungen richten wir nach Ihrem Setup aus. Ob GitHub, GitLab, Forgejo/Gitea oder eine andere Oberfläche: Wir arbeiten mit dem, was Ihr Team tatsächlich benutzt, damit die Abläufe direkt übertragbar sind.
Was bedeutet „saubere Historie“ konkret, und ist das nicht Geschmackssache?: Teilweise ja – deshalb erarbeiten wir keine Doktrin, sondern die Konsequenzen. Eine Historie ist dann gut, wenn sie die Fragen beantwortet, die Sie ihr später stellen: Wann kam dieser Fehler rein, was gehörte zu dieser Änderung, was lässt sich gefahrlos zurücknehmen. Welche Konventionen das erreichen, entscheidet Ihr Team – wir zeigen die Optionen samt Preis.
Ist das eine reine Git-Schulung oder geht es auch um den Entwicklungsprozess?: Beides, weil das eine ohne das andere wenig taugt. Branching-Strategie, Review-Kultur und CI-Anbindung hängen zusammen: Eine Strategie, die nicht zu Ihrem Release-Rhythmus passt, wird umgangen, egal wie gut sie auf dem Papier aussieht.

Fachartikel zum Thema

Vertiefendes aus unserem Blog – dieselben Themen, ausführlich.

17. Juli 2026 · 7 Min. Lesezeit

Hardware-in-the-Loop-Testing: CI/CD mit echter Embedded-Hardware

Warum ein Hardware-in-the-Loop-Prüfstand das fehlende Stück für echtes CI/CD auf Embedded-Geräten ist: Treiber-, Timing- und Integrationsfehler auf echter Hardware finden.

Testing
CI/CD
Hardware-in-the-Loop

Weitere Schulungen

3 Tage

Diese Schulung für Ihr Team?

Sagen Sie uns kurz, wie viele Teilnehmer, welcher Stand und welcher Zeitrahmen – wir machen Ihnen einen Vorschlag samt Terminen.

Projekt anfragen