Seite 5 - Git

"Staging Area" ist nur ein Spitzname. Dahinter steckt eine reale, binäre Datei mit dokumentiertem Format, eigener Prüfsumme und Stage-Nummern pro Eintrag. Dieser Artikel geht direkt in die Internals: Dateiformat, was git add technisch schreibt, wie git status und git diff den Index als Angelpunkt nutzen, wie man ihn mit git ls-files und git update-index direkt inspiziert und manipuliert, und warum git add -p überhaupt nur funktioniert, weil der Index vom Working Directory entkoppelt ist.

Ein Commit ohne Ref ist für Git praktisch unsichtbar. Branches, Tags und HEAD sind allesamt nur benannte Zeiger, die aus einer losen Ansammlung von Objekten einen navigierbaren Verlauf machen. Dieser Artikel zeigt, wie .git/refs/heads, .git/refs/tags und packed-refs auf der Festplatte aufgebaut sind, wie HEAD in zwei Schritten zu einem Commit aufgelöst wird, und wie man Refs mit git show-ref, git symbolic-ref und git update-ref direkt inspiziert und manipuliert.

Jeder kann git config user.name und user.email auf einen beliebigen Namen setzen und Commits im Namen eines Kollegen erstellen, ohne dass Git das verhindert. Dieser Artikel zeigt, wie GPG- und SSH-basierte Commit-Signaturen kryptographisch beweisen, wer einen Commit tatsächlich erstellt hat, wie man Schlüssel einrichtet, Signaturen verifiziert und signierte Commits über Branch-Protection-Regeln im Team erzwingt.

Git Hooks sind Skripte, die Git automatisch bei bestimmten Ereignissen wie Commit, Push oder Merge ausführt, lokal im Verzeichnis .git/hooks und serverseitig im blanken Repository. Dieser Artikel zeigt, wie sich Client und Server Hooks unterscheiden, wie ein pre-commit Hook Schritt für Schritt entsteht, wie Git Exit Codes interpretiert und wie core.hooksPath Hooks endlich teamweit versionierbar macht.

Eine sauber konfigurierte .gitattributes-Datei löst Probleme, die viele PHP-Teams für unvermeidbar halten: CRLF-Rauschen zwischen Windows und Linux, aufgeblähte Deployment-Archive, verzerrte GitHub-Sprachstatistik durch Vendor-Code und unlesbare Pull-Request-Diffs bei generierten oder minifizierten Dateien. Dieser Artikel zeigt jede relevante Direktive an echten Beispielen für PHP- und Magento-Projekte, inklusive Zeilenenden, export-ignore, linguist-Attributen und Diff-Treibern für den produktiven Entwickleralltag.

Eine verworrene Git-History mit hunderten WIP-Commits macht Bisect nutzlos, Reviews mühsam und Blame unzuverlässig. Klare Konventionen wie atomare Commits, Rebase vor dem Merge und disziplinierte Commit-Messages verwandeln das Log in ein verlässliches Werkzeug für Debugging und Nachvollziehbarkeit, ohne die Geschwindigkeit im Team zu bremsen.

Git Submodules versprechen, mehrere Repositories sauber zu verzahnen, doch in der Praxis sorgen vergessene Updates, ein verwirrender Detached HEAD Zustand und divergierende Commit Pins im Team regelmäßig für Frust. Dieser Artikel erklärt, wie Submodules technisch funktionieren, vergleicht sie mit git subtree, Composer basierten Abhängigkeiten und Monorepos, und zeigt, welches Werkzeug für typische Magento Multi Repo Setups tatsächlich passt.

IDE

{ }

PhpStorm · Git · Version Control · PHP

Git in PhpStorm: Branches, Rebase, Stash
und Partial Commits sauber nutzen

Wer Git nur über das Terminal bedient, verzichtet auf die leistungsfähigsten Werkzeuge, die PhpStorm für visuelle Konfliktlösung, interaktiven Rebase und präzise Commit-Auswahl bietet. Diese Anleitung zeigt, wie der gesamte Git-Workflow — von Feature-Branches bis zu sauber geteilten Commits — direkt in der IDE abläuft.

12 Min. Lesezeit Branches · Rebase · Stash · Partial Commits · Merge-Konflikte PhpStorm 2024.x · Git 2.x · PHP 8.x

Inhaltsverzeichnis

1. 1. Warum Git in der IDE statt nur im Terminal?
2. 2. Branches anlegen, wechseln und verwalten
3. 3. Selective Staging: nur die richtigen Änderungen committen
4. 4. Partial Commits: Hunk-Auswahl in PhpStorm
5. 5. Stash und Shelf: Work-in-Progress sichern
6. 6. Merge-Konflikte visuell lösen
7. 7. Interaktiver Rebase in PhpStorm
8. 8. Git Log und Blame produktiv einsetzen
9. 9. Terminal vs. IDE: Wann was?
10. 10. Zusammenfassung
11. 11. FAQ

1. Warum Git in

Monorepo oder Polyrepo ist eine der folgenreichsten Architekturentscheidungen für Git-Projekte, weil sie Commit-Verhalten, Zugriffsrechte, CI/CD-Pipelines und die tägliche Entwicklerroutine über Jahre hinweg prägt. Dieser Artikel vergleicht beide Strategien anhand konkreter Kriterien wie Teamgröße, Kopplung und Tooling und zeigt, wie Magento-Agenturen Kundenprojekte und Custom-Module sinnvoll zwischen app/code und eigenen Composer-Paketen aufteilen.

Ein pre-commit Hook läuft, bevor Git den Commit tatsächlich erstellt, und kann ihn bei Regelverstößen vollständig verhindern. Dieser Artikel zeigt, welche Prüfungen wie Linting, Formatierung und schnelle Unit-Tests dort sinnvoll sind, warum Geschwindigkeit entscheidend ist, und wie sich Hand-geschriebene Skripte gegenüber dem pre-commit Framework schlagen.