Ein Monorepo (kurz für "Monorepository") ist ein einziges Versionsverwaltungssystem (z.B. ein Git-Repository), in dem der Code für mehrere Projekte oder Dienste gespeichert wird. Im Gegensatz zu einem "Multirepo", bei dem jedes Projekt oder jeder Dienst in einem eigenen Repository verwaltet wird, umfasst ein Monorepo alle Projekte in einem einzigen Repository.

Merkmale und Vorteile eines Monorepos:

1. Gemeinsame Codebasis: Alle Projekte teilen sich eine einzige Codebasis, was die Zusammenarbeit zwischen verschiedenen Teams erleichtert. Änderungen, die sich auf mehrere Projekte auswirken, können gleichzeitig gemacht und getestet werden.

2. Einfache Code-Synchronisation: Da alle Projekte denselben Versionsverlauf nutzen, ist es einfacher, gemeinsame Bibliotheken oder Abhängigkeiten konsistent zu halten.

3. Wiederverwendbarkeit: In einem Monorepo ist es einfacher, wiederverwendbare Module oder Bibliotheken zwischen Projekten zu teilen.

4. Integrierte Versionskontrolle: Es gibt eine zentrale Versionskontrolle, sodass Änderungen in einem Projekt sofort auch andere Projekte betreffen können.

5. Skalierbarkeit: Große Unternehmen wie Google oder Facebook nutzen Monorepos, um Tausende von Projekten und Entwicklern unter einem einzigen Repository zu organisieren.

Nachteile eines Monorepos:

• Komplexität des Builds: Der Build-Prozess kann komplizierter werden, da er die Abhängigkeiten zwischen vielen verschiedenen Projekten berücksichtigen muss.

• Leistungsprobleme: Bei sehr großen Repositories können Versionskontrollsysteme wie Git langsamer arbeiten, da sie mit der Größe des Repos kämpfen.

Ein Monorepo ist besonders sinnvoll, wenn verschiedene Projekte eng miteinander verzahnt sind und es oft zu Überschneidungen oder Abhängigkeiten kommt.

CaptainHook ist ein Git-Hook-Manager für PHP, der es Entwicklern ermöglicht, automatisierte Aufgaben im Zusammenhang mit Git-Repositories durchzuführen. Es erleichtert das Einrichten und Verwalten von Git-Hooks, also Skripten, die zu bestimmten Zeitpunkten im Git-Workflow automatisch ausgeführt werden (z. B. vor dem Committen oder Pushen von Code). Dies ist besonders nützlich, um Codestandards durchzusetzen, Tests laufen zu lassen, Commit-Nachrichten zu überprüfen oder fehlerhaften Code zu verhindern.

CaptainHook lässt sich einfach über Composer in Projekte integrieren und bietet Flexibilität, um benutzerdefinierte Hooks und Plugins zu erstellen. Es unterstützt verschiedene PHP-Versionen, wobei die neueste Version PHP 8.0 erfordert​.

Breaking Changes (auf Deutsch etwa "brechende Änderungen") sind Änderungen an einer Software, einem API oder einer Bibliothek, die dazu führen, dass bestehender Code oder Abhängigkeiten nicht mehr wie erwartet funktionieren. Diese Änderungen brechen also die Abwärtskompatibilität, wodurch ältere Versionen des Codes, die auf die vorherige Version angewiesen sind, nicht mehr ohne Anpassungen laufen.

Typische Beispiele für Breaking Changes sind:

1. Änderung oder Entfernung von Funktionen: Eine Funktion, die zuvor vorhanden war, wird entweder entfernt oder verhält sich anders.
2. Änderung von Schnittstellen: Wenn die Parameter einer Methode oder API geändert werden, kann bestehender Code, der diese Methode nutzt, Fehler werfen.
3. Änderungen in der Datenstruktur: Änderungen an Datenformaten oder Datenmodellen können dazu führen, dass bestehender Code inkompatibel wird.
4. Änderung des Verhaltens: Wenn das Verhalten eines Codes sich grundlegend ändert (z.B. von synchron zu asynchron), erfordert dies oft Anpassungen im aufrufenden Code.

Um mit Breaking Changes umzugehen, müssen Entwickler ihre Software oft aktualisieren oder anpassen, um mit den neuen Versionen kompatibel zu bleiben. In der Regel werden Breaking Changes in Major-Versionen einer Software veröffentlicht, um die Nutzer auf die Inkompatibilitäten aufmerksam zu machen.

Ein Changelog ist eine Datei oder ein Dokument, das die Änderungen und Updates an einer Software oder einem Projekt auflistet. Es enthält eine chronologische Aufzeichnung von neuen Funktionen, Fehlerbehebungen, Verbesserungen und Breaking Changes (Änderungen, die die Rückwärtskompatibilität brechen). Ein Changelog hilft Benutzern und Entwicklern, den Entwicklungsverlauf einer Software zu verfolgen und zu verstehen, welche Änderungen in einer bestimmten Version vorgenommen wurden.

Wichtige Bestandteile eines Changelogs:

1. Versionsnummern: Jede Änderung wird mit der entsprechenden Versionsnummer versehen (z. B. 1.2.0), oft basierend auf SemVer (Semantic Versioning).
2. Änderungstypen: Die Änderungen sind in Kategorien eingeteilt, wie:
   • Added: Neue Funktionen oder Features.
   • Changed: Änderungen an bestehenden Funktionen.
   • Fixed: Fehlerbehebungen.
   • Deprecated: Veraltete Funktionen, die in zukünftigen Versionen entfernt werden.
   • Removed: Entfernte Funktionen.
   • Security: Sicherheitsrelevante Verbesserungen oder Patches.
3. Beschreibung der Änderungen: Jede Änderung wird kurz und prägnant beschrieben, oft mit zusätzlichen Details, wenn nötig.

Beispiel eines Changelogs:

# Changelog

## [1.2.0] - 2023-09-19
### Added
- New user authentication system.
- Ability to reset passwords via email.

### Fixed
- Resolved bug with session timeout after 30 minutes of inactivity.

### Changed
- Updated the UI for the login screen.

## [1.1.0] - 2023-08-10
### Added
- New dark mode theme for the dashboard.

### Security
- Patched vulnerability in file upload functionality.

Vorteile eines Changelogs:

• Transparenz: Ein Changelog zeigt klar, was sich von Version zu Version geändert hat.
• Dokumentation: Es dient als nützliches Referenzdokument für Benutzer, die wissen möchten, welche Funktionen oder Fehlerbehebungen in einer neuen Version enthalten sind.
• Rückverfolgbarkeit: Entwickler können anhand des Changelogs frühere Änderungen nachvollziehen, was bei der Fehlersuche oder bei Upgrades wichtig ist.

Changelogs sind in Open-Source-Projekten besonders weit verbreitet, da sie für die Community eine nachvollziehbare und klare Übersicht über die Entwicklung eines Projekts bieten.

Ein Merge-Konflikt tritt in Versionskontrollsystemen wie Git auf, wenn zwei verschiedene Änderungen an derselben Datei nicht automatisch zusammengeführt (gemerged) werden können. Das passiert, wenn mehrere Entwickler gleichzeitig an denselben Teilen einer Datei arbeiten und deren Änderungen kollidieren.

Beispiel eines Merge-Konflikts:

Stellen Sie sich vor, zwei Entwickler arbeiten an derselben Datei in einem Projekt:

1. Entwickler A ändert Zeile 10 der Datei und fügt diese Änderung in den Hauptzweig (z.B. main) ein.
2. Entwickler B ändert ebenfalls Zeile 10, aber in einem separaten Zweig (z.B. feature-branch).

Wenn Entwickler B versucht, seinen Zweig (feature-branch) mit dem Hauptzweig (main) zusammenzuführen, erkennt Git, dass dieselbe Zeile in beiden Zweigen geändert wurde, und kann nicht automatisch entscheiden, welche Änderung beibehalten werden soll. Dies führt zu einem Merge-Konflikt.

Wie wird ein Merge-Konflikt gelöst?

• Git markiert die betroffenen Stellen in der Datei und zeigt die konkurrierenden Änderungen an.
• Der Entwickler muss dann manuell entscheiden, welche der Änderungen beibehalten werden soll oder ob eine Kombination aus beiden Änderungen sinnvoll ist.
• Nach der Behebung des Konflikts kann die Datei erneut gemerged und der Konflikt gelöst werden.

Typische Konflikt-Markierungen:

In der Datei sieht ein Konflikt oft so aus:

<<<<<<< HEAD
Änderung von Entwickler A
=======
Änderung von Entwickler B
>>>>>>> feature-branch

Hier muss der Entwickler den Konflikt manuell auflösen und die Datei entsprechend anpassen.

Ein Interactive Rebase ist eine erweiterte Funktion des Versionskontrollsystems Git, mit der du mehrere Commits in einem Branch überarbeiten, neu anordnen, zusammenführen oder löschen kannst. Im Gegensatz zu einem normalen Rebase, bei dem die Commits einfach auf einen neuen Basis-Commit „umgehängt“ werden, bietet ein interaktiver Rebase die Möglichkeit, jeden Commit in der Rebase-Reihe individuell zu bearbeiten.

Wann und warum wird ein Interactive Rebase verwendet?

• Aufräumen der Commit-Historie: Vor dem Zusammenführen eines Branches in den Hauptzweig (z.B. main oder master) kannst du die Commit-Historie bereinigen, indem du unnötige Commits zusammenführst oder entfernst.
• Reihenfolge ändern: Du kannst die Reihenfolge der Commits ändern, wenn sie in einer bestimmten Reihenfolge sinnvoller erscheinen.
• Fixes zusammenfassen: Kleinere Fehlerkorrekturen, die nach einem Feature-Commit gemacht wurden, können mit dem ursprünglichen Commit zusammengeführt werden, um eine übersichtlichere und verständlichere Historie zu erstellen.
• Commit-Messages bearbeiten: Du kannst die Commit-Nachrichten ändern, um klarere und aussagekräftigere Nachrichten zu hinterlassen.

Wie funktioniert ein Interactive Rebase?

Angenommen, du möchtest die letzten 4 Commits eines Branches bearbeiten, führst du folgendes Kommando aus:

git rebase -i HEAD~4

Ablauf:

1. Auswahl der Commits:

• Nachdem du den Befehl eingegeben hast, öffnet sich ein Texteditor mit einer Liste der ausgewählten Commits. Jeder Commit ist mit dem Schlüsselwort pick markiert, gefolgt von der Commit-Nachricht.

Beispiel:

pick a1b2c3d Commit message 1
pick b2c3d4e Commit message 2
pick c3d4e5f Commit message 3
pick d4e5f6g Commit message 4

2. Bearbeiten der Commits:

• Du kannst die pick-Befehle durch andere Schlüsselwörter ersetzen, um verschiedene Aktionen durchzuführen:
  • pick: Behalte den Commit unverändert.
  • reword: Ändere die Commit-Nachricht.
  • edit: Stoppt das Rebase, damit du Änderungen am Commit vornehmen kannst.
  • squash: Kombiniere den Commit mit dem vorherigen.
  • fixup: Kombiniere den Commit mit dem vorherigen, ohne die Commit-Nachricht zu behalten.
  • drop: Entferne den Commit.

Beispiel für eine bearbeitete Liste:

pick a1b2c3d Commit message 1
squash b2c3d4e Commit message 2
reword c3d4e5f New commit message 3
drop d4e5f6g Commit message 4

3. Speichern und Ausführen:

• Nachdem du die Liste angepasst hast, speicherst du und schließt den Editor. Git führt dann die Rebase mit den angegebenen Aktionen durch.

4. Konflikte lösen:

• Falls es während des Rebases zu Konflikten kommt, musst du diese manuell beheben und dann den Rebase-Prozess mit git rebase --continue fortsetzen.

Wichtige Hinweise:

• Unterscheidung zwischen lokaler und gemeinsamer Historie: Interactive Rebase sollte in der Regel nur auf Commits angewendet werden, die noch nicht mit anderen geteilt wurden (z.B. auf einem Remote-Repository), da das Umschreiben der Historie nachteilige Auswirkungen auf andere Entwickler haben kann.
• Sicherung: Es ist ratsam, vor einem Rebase eine Sicherung (z.B. durch einen temporären Branch) zu erstellen, um im Falle eines Fehlers zur ursprünglichen Historie zurückkehren zu können.

Zusammenfassung:

Interactive Rebase ist ein mächtiges Werkzeug in Git, das es ermöglicht, die Commit-Historie zu bereinigen, zu reorganisieren und zu optimieren. Es erfordert etwas Übung und Verständnis der Git-Konzepte, bietet aber eine große Flexibilität, um die Geschichte eines Projekts klar und nachvollziehbar zu gestalten.