Anleitung: CONTENIDO Entwicklung & GitHub
Verfasst: Sa 24. Jan 2026, 22:31
Hallo zusammen,
in diesem Beitrag ist eine Anleitung für alle, die bei der Entwicklung von CONTENIDO mitwirken möchten.
Das CONTENIDO-Repository ist auf GitHub und jeder, der einen GitHub-Zugang hat, kann bei der Entwicklung mitwirken, sei es Korrekturen, Aktualisierung der Dokumentation oder Entwicklung neuer Features. Das Letztere sollte vorab angestimmt werden, d.h. wir sollten das gemeinsam entscheiden, was für neue Featuren in CONTENIDO hinzukommen sollen.
In CONTENIDO-GitHub-Projekt gibt es eine Datei, in der beschrieben ist, wie man am Projekt mitwirken kann.
https://github.com/CONTENIDO/CONTENIDO/ ... IBUTING.md
Hier ein grober Überblick über die Schritte.
Die Sprache ist in Englisch, Tickets und Commit-Messages bitte in Englisch verfassen.
Ticket (GitHub-Issue) erstellen
Kurzen und selbsterklärenden Titel abgeben.
In der Beschreibung sollte drinstehen, was der Fehler oder die Aufgabe ist.
Rechts den Typ (Bug, Feature, Task) des Tickets auswählen.
Als Projekt „Kanban board“ auswählen.
Bei Milestone lässt sich definieren, für welche Version das gedacht ist.
Branch erzeugen
Da gibt es verschiedene Wege, GitHub, lokal über git, IDE, oder Git-Client. Hier wird der Weg in GitHub beschrieben.
Für jede Änderung, die für die develop-Branch gedacht ist, sollte auch ein neue Branch von develop abgezweigt werden.
In der Detail-Ansicht eines Tickets, gibt es in der rechten Spalte ein Link "Create a branch" for this issue or link a pull request.
Im Dialog wird schon der Branch-Name vordefiniert, z.B.
Da bitte den Typ "<type>/" voranstellen, z.B. "bug/123-title-of-the-issue" (oder feat/ oder task/) und auf "Create branch" klicken.
Achteet bitte darauf, dass alles in Kleinschreibweise bleibt, keine Leer-/Sonderzeichen und Umlaute vorkommen.
Danach kann man bei sich lokal mit `git fetch` den neuen Stand von Remote holen. Wer will kann auch mit der Online-IDE (VS-Code) arbeiten, die über GitHub-Codespaces zur Verfügung steht.
Die neue Branch auschecken.
Die Änderungen/Korrekturen machen.
Lokal committen. Bitte achtet hier auf das Format der Commit-Message. Wunsch wäre, dass wir uns zukünftig an die in "Conventional Commits" beschriebene Vorgehensweise anlehnen.
Es reicht aber aus, wenn die Commit-Message wie folgt aussieht:
Beispiel:
Die Änderungen auf Remote pushen.
In GitHub oder über die IDE/Git-Client den Pull-Request erstellen. Wenn ihr von der develop-Branch abgezweigt habt, sollten der Pull-Request auch auf dem develop-Brach gehen.
Bitte achtet auf folgendes:
Der Prozess von der Ticket Erstellung bis zum Pull-Request ist der standardisierte Workflow bei der Softwareentwicklung und es stellt sicher, dass Code-Änderungen nachvollziehbar bleiben.
Hier ist die Erläuterung der einzelnen Schritte:
Das Format für die Git Commit-Message wird gebraucht, um daraus einfach die Changelog zu erstellen. Es steht der Typ (fix:, feat:, docs:, usw.) drin, die Ticket-Nummer ([#123]), und der Titel des Tickets. Zusätzlich ist entscheidend, um die Historie eines Softwareprojekts lesbar, durchsuchbar und maschinell auswertbar zu machen.
Conventional Commits bieten hierfür eine standardisierte Spezifikation (z. B. feat:, fix:, chore:), die folgende Vorteile bietet:
xmurrix
in diesem Beitrag ist eine Anleitung für alle, die bei der Entwicklung von CONTENIDO mitwirken möchten.
Das CONTENIDO-Repository ist auf GitHub und jeder, der einen GitHub-Zugang hat, kann bei der Entwicklung mitwirken, sei es Korrekturen, Aktualisierung der Dokumentation oder Entwicklung neuer Features. Das Letztere sollte vorab angestimmt werden, d.h. wir sollten das gemeinsam entscheiden, was für neue Featuren in CONTENIDO hinzukommen sollen.
In CONTENIDO-GitHub-Projekt gibt es eine Datei, in der beschrieben ist, wie man am Projekt mitwirken kann.
https://github.com/CONTENIDO/CONTENIDO/ ... IBUTING.md
Hier ein grober Überblick über die Schritte.
Die Sprache ist in Englisch, Tickets und Commit-Messages bitte in Englisch verfassen.
Ticket (GitHub-Issue) erstellen
Kurzen und selbsterklärenden Titel abgeben.
In der Beschreibung sollte drinstehen, was der Fehler oder die Aufgabe ist.
Rechts den Typ (Bug, Feature, Task) des Tickets auswählen.
Als Projekt „Kanban board“ auswählen.
Bei Milestone lässt sich definieren, für welche Version das gedacht ist.
Branch erzeugen
Da gibt es verschiedene Wege, GitHub, lokal über git, IDE, oder Git-Client. Hier wird der Weg in GitHub beschrieben.
Für jede Änderung, die für die develop-Branch gedacht ist, sollte auch ein neue Branch von develop abgezweigt werden.
In der Detail-Ansicht eines Tickets, gibt es in der rechten Spalte ein Link "Create a branch" for this issue or link a pull request.
Im Dialog wird schon der Branch-Name vordefiniert, z.B.
Code: Alles auswählen
123-title-of-the-issueAchteet bitte darauf, dass alles in Kleinschreibweise bleibt, keine Leer-/Sonderzeichen und Umlaute vorkommen.
Danach kann man bei sich lokal mit `git fetch` den neuen Stand von Remote holen. Wer will kann auch mit der Online-IDE (VS-Code) arbeiten, die über GitHub-Codespaces zur Verfügung steht.
Die neue Branch auschecken.
Die Änderungen/Korrekturen machen.
Lokal committen. Bitte achtet hier auf das Format der Commit-Message. Wunsch wäre, dass wir uns zukünftig an die in "Conventional Commits" beschriebene Vorgehensweise anlehnen.
Es reicht aber aus, wenn die Commit-Message wie folgt aussieht:
Code: Alles auswählen
<Typ>: [#<IssueNummer>] - <IssueTitel>
<Beschreibung>
Code: Alles auswählen
fix: [#123] – Title of the issue
Describe the changes made or the errors fixed here.
In GitHub oder über die IDE/Git-Client den Pull-Request erstellen. Wenn ihr von der develop-Branch abgezweigt habt, sollten der Pull-Request auch auf dem develop-Brach gehen.
Bitte achtet auf folgendes:
- Formatierung des Quellcodes, falls ihr Änderungen am Quelltext macht. Nutzt am besten den PSR-12 als Coding-Standard. Da gibt es für IDEs entsprechende Erweiterungen, die darauf achten, dass der Coding-Standard eingehalten wird. Das ist nicht der originale Coding-Standard von CONTENIDO, aber davon sollten wir weg, PSR-12 ist fast schon ein Standard. Ihr könnt euch an die im Quelltext vorhandene Formatierung halten. Schaut euch, wie der Programmierstil in der Datei ist, und haltte euch bei den Änderungen daran.
- Keine Tabs, sondern 4 Leerzeichen
- In der aktuellen develop-Branch als Zeilenende-Zeichen CRLF (Windows) nutzen. In der PHP 8.4 Branch feature/529-php-84-support ist das auf LF umgestellt, in zukünftigen Branches sollten wir uns dann danach richten.
Der Prozess von der Ticket Erstellung bis zum Pull-Request ist der standardisierte Workflow bei der Softwareentwicklung und es stellt sicher, dass Code-Änderungen nachvollziehbar bleiben.
Hier ist die Erläuterung der einzelnen Schritte:
- Ticket erstellen: Dient der Dokumentation und Priorisierung. Es definiert das „Warum“ hinter einer Änderung, damit jeder im Team den Kontext und die Anforderungen versteht.
- Branch für Ticket erstellen: Ermöglicht Isolierung. Entwickler arbeiten in einer eigenen Umgebung, ohne den stabilen Hauptcode (Main/Master) zu beeinflussen oder Kollegen bei deren Arbeit zu stören.
- Änderungen committen: Erstellt Checkpoints. Kleine, logische Einheiten machen den Fortschritt transparent und ermöglichen es, bei Fehlern präzise zu älteren Versionen zurückzukehren.
- Auf Remote pushen: Dient der Datensicherung und Zusammenarbeit. Der Code liegt nicht nur lokal auf einem Rechner, sondern ist auf dem Server (GitHub) für das Team verfügbar.
- Pull-Request (PR) erstellen: Dies ist der entscheidende Qualitätsfilter. Bevor der Code in das Hauptprojekt fließt, erfolgt ein Code Review durch Kollegen. Fehler werden minimiert, Wissen wird geteilt und die Einhaltung von Standards wird sichergestellt.
Das Format für die Git Commit-Message wird gebraucht, um daraus einfach die Changelog zu erstellen. Es steht der Typ (fix:, feat:, docs:, usw.) drin, die Ticket-Nummer ([#123]), und der Titel des Tickets. Zusätzlich ist entscheidend, um die Historie eines Softwareprojekts lesbar, durchsuchbar und maschinell auswertbar zu machen.
Conventional Commits bieten hierfür eine standardisierte Spezifikation (z. B. feat:, fix:, chore:), die folgende Vorteile bietet:
- Automatisierte Changelogs: Durch die einheitliche Struktur können Tools automatisch Versionshinweise generieren, die genau auflisten, welche Features (feat) hinzugefügt oder Fehler (fix) behoben wurden.
- Semantische Versionierung (SemVer): Der Typ des Commits (und Zusätze wie ! für Breaking Changes) erlaubt es automatisierten Systemen, die nächste Versionsnummer (Patch, Minor oder Major) eigenständig zu bestimmen.
- Schnellere Orientierung: Entwickler sehen auf einen Blick, welche Art von Änderung vorgenommen wurde, ohne den gesamten Code prüfen zu müssen.
- Tool-Unterstützung: Der Einsatz von Commitizen oder commitlint stellt sicher, dass alle Teammitglieder denselben Standard einhalten und verhindert ungültige Nachrichten bereits beim Erstellen.
- Konsistenz im Team: Standards verhindern endlose Diskussionen über Formatierungen (z. B. Einrückungen oder Klammersetzung). Mit PSR-12 folgt das gesamte Team einer universellen „Sprache“, was das Onboarding neuer Mitglieder massiv beschleunigt.
- Reduzierte kognitive Last: Da der Code einem festen Muster folgt, können Entwickler Logikfehler schneller finden, anstatt Zeit damit zu verschwenden, unübersichtliche Formatierungen zu entziffern.
- Interoperabilität: PSR-12 (Extended Coding Style Guide) ist eine Spezifikation der PHP Framework Interop Group (PHP-FIG). Sie stellt sicher, dass PHP-Komponenten verschiedener Bibliotheken und Frameworks nahtlos zusammenarbeiten und eine einheitliche Code-Basis bilden.
- Automatisierung: Standards wie PSR-12 ermöglichen den Einsatz von Tools wie dem PHP Coding Standards Fixer (PHP CS Fixer) oder Easy Coding Standard, die Formatierungsfehler automatisch korrigieren, bevor der Code überhaupt eingecheckt wird.
- Langfristige Wartbarkeit: Sauberer Code nach Industriestandards ist weniger fehleranfällig und lässt sich leichter erweitern, was die Gesamtkosten der Softwareentwicklung senkt.
xmurrix