Seite 5 - Git

Wer Merge und Rebase austauschbar nutzt, riskiert verlorene Commits, verwirrende Historie und Force-Push-Chaos im Team. Beide Befehle integrieren divergierende Branches, aber auf grundlegend unterschiedliche Weise. Dieser Artikel erklaert die interne Mechanik beider Operationen und liefert einen klaren, praxistauglichen Entscheidungsrahmen für den taeglichen Einsatz.

Mit zunehmender Größe sammeln sich in jedem Repository lose Objekte, wachsende Pack-Dateien und ein immer teurer werdender Commit-Graph an. Der Befehl git maintenance ersetzt das grobe, gelegentliche git gc durch mehrere granulare, planbare Wartungsaufgaben, die im Hintergrund laufen, ohne die tägliche Arbeit zu stören.

Eine rohe diff-Ausgabe ist technisch korrekt, aber schwer zu lesen, weil Zeilen mit + und minus optisch kaum auffallen. Dieser Artikel zeigt, wie eine farbige Diff-Ausgabe in Bash-Skripten entsteht, von fertigen Werkzeugen wie colordiff und git diff bis zur eigenen ANSI-Einfärbung mit awk für Sonderfälle, die kein Standardwerkzeug abdeckt.

Wer nach jedem Pull vergisst, Composer zu aktualisieren, verliert Zeit mit kryptischen Fehlermeldungen. Der post-merge Hook erledigt solche Routineaufgaben automatisch, ganz ohne daran denken zu müssen.

Sobald ein Projekt Code aus einem anderen Repository einbinden muss, stehen zwei eingebaute Git-Mechanismen zur Auswahl: Submodule und Subtree. Beide lösen dasselbe Grundproblem, externe Historie im eigenen Repository referenzierbar zu machen, aber mit vollkommen unterschiedlichen Konsequenzen für Checkout, CI-Pipelines und die Frage, wer welchen Code wo pflegt. Dieser Artikel vergleicht beide Ansätze anhand konkreter Workflows und ordnet ein, wann welche Variante in einem Magento-Kontext sinnvoll ist.

Wenn zwischen Commit und Review acht Stunden liegen, reicht ein guter Branching-Plan nicht mehr aus. Verteilte Teams brauchen einen Git-Workflow, der auf asynchrone Kommunikation ausgelegt ist.

Wer mehrere Feature-Branches gleichzeitig prüfen muss, stößt schnell an die Grenzen eines einzelnen Docker-Compose-Stacks: Portkonflikte, geteilte Datenbanken und Namenskollisionen bei Containern und Netzwerken. COMPOSE_PROJECT_NAME in Kombination mit Profiles löst genau dieses Problem, indem jede Umgebung sauber isoliert nebeneinander läuft.

Git Flow und GitHub Flow lösen dasselbe Problem auf unterschiedliche Weise: wie ein Team parallel an Features arbeitet, ohne sich gegenseitig zu blockieren. Dieser Artikel erklärt beide Branching-Strategien im Detail, zeigt echte Git-Befehle für den Alltag und liefert eine klare Empfehlung, welches Modell für kleine und welches für große Teams besser passt.

Jede CI-Pipeline, die bei jedem Lauf Dependencies neu installiert oder Build-Artefakte komplett neu erzeugt, verschenkt Zeit und Geld. Ein Bash-Skript, das den Cache-Key konsequent aus einer Hashsumme relevanter Dateien bildet, sorgt dafür, dass ein Cache automatisch invalidiert wird, sobald sich etwas ändert, und ansonsten zuverlässig wiederverwendet wird.

Wer Commit-Messages ohne Validierung durchwinkt, sammelt über Monate eine Historie aus Nachrichten wie fix und wip, die sich weder für Changelogs noch für automatisierte Releases nutzen lässt. Der commit-msg-Hook prüft jede Nachricht, bevor der Commit entsteht, und erzwingt mit commitlint und Husky ein konsistentes Format, das Tools wie semantic-release zuverlässig auswerten können.