Ich will den Core patchen. Was ist zu tun?

Hast Du Zeit? Viel Zeit? Na dann los:

1.) Du brauchst einen TYPO3-Account

Geh auf die TYPO3-Seite und erstelle Dir einen Benutzeraccount. Du findest Ihr ein bisschen versteckt oben unter "Login" und dann in dem kleinen Fenster unten bei "Sign up!". Nachdem Du den Registrierungsprozess vollendet hast gehörst Du zur TYPO3-Gemeinde. Willkommen :-) Achte gut auf Deinen TYPO3-Account, denn er ist nicht nur die Eintrittskarte für www.typo3.org, sondern auch für sämtliche Unterprojekte wie z.B.

http://svn.typo3.org

http://review.typo3.org

http://forge.typo3.org

http://git.typo3.org

und noch Einigen mehr.

2.) Du musst der CLA zustimmen

Um am Quellcode von TYPO3 Flow mitzuentwickeln wird eine sogenannte Contributor License Agreement benötigt. Diese klärt die Nutzerrechte zwischen der TYPO3-Association und Euch (dem Programmierer). Peter Kraume hat dazu einen sehr ausführlichen Bericht auf typo3blogger gepostet.

Alle Projekte, die auf Basis von TYPO3 Flow entwickelt wurden und zurück portiert wurden in den Quellcode von TYPO3 CMS wie zum Beispiel Extbase und Fluid erfordern ebenfalls diese unterschriebene CLA. Ohne CLA könnt Ihr keine Patches für diese Extensions committen.

Nur der reine TYPO3-Quellcode und die NICHT von TYPO3 Flow zurück portierten System-Extensions benötigen diese CLA nicht.

Es gibt wohl schon Überlegungen, die CLA auch für die TYPO3-Quellen erforderlich zu machen. Da es also nur noch eine Frage der Zeit ist, könnt Ihr die CLA auch jetzt schon unterschreiben. So zur Vorsorge halt...

3.) Einen SSH-Key erstellen

Die Verbindung zwischen Euch und dem TYPO3-Server muss immer abgesichert sein. Dafür gibt es SSH-Keys. Github hat dazu eine gute englische Dokumentation.

a.) Loggt Euch mit Eurem TYPO3-Account auf dem Reviewserver ein

b.) Klickt dann oben rechts auf "Settings" und dann links auf "SSH Public Keys"

Wenn Ihr bereits über einen Public SSH-Key verfügt, dann könnt Ihr diesen nun hier eintragen und die weiteren Punkte von Schritt 3 überspringen.

c.) Prüft, ob Ihr bereits einen SSH-Key eingerichtet habt

Öffnet eine Shell und wechselt in das versteckte ssh-Verzeichnis:

cd ~/.ssh

Mit "ls -l" könnt Ihr Euch den Inhalt diesen Verzeichnisses auflisten lassen.

Falls Ihr in diesem Verzeichnis bereits einen Key erstellt habt, dann editiert die Datei (üblicherweise id_rsa.pub) und kopiert den Inhalt wie unter Punkt b) erklärt auf den Reviewserver.

d.) Das versteckte Verzeichnis erstellen

Falls das Verzeichnis noch nicht existieren sollte, dann könnt Ihr es folgendermaßen erstellen:

mkdir ~/.ssh

e.) Den neuen SSH-Key generieren

Gebt folgenden Befehl ein:

ssh-keygen -t rsa -C "DeineEmailAdresse"

Ihr werdet gefragt wohin der SSH-Key abgelegt werden soll. Wenn Ihr noch kein SSH-Key generiert habt, dann könnt Ihr den Pfad wie vorgeschlagen mit Enter bestätigen. Falls Ihr parallel zu Eurem bereits vorhandenem SSH-Key einen zusätzlichen, nur für TYPO3 gültigen SSH-Key generieren wollt, müsst Ihr den vorgeschlagenen Dateinamen anpassen. Z.B. /home/stefan/.ssh/typo3

Es folgt die Frage nach einer Passphrase. Nennen wir es mal vereinfacht "Passwort". Ihr könnt selber entscheiden, ob Ihr Eurem SSH-Key ein Passwort mitgeben wollt. Wenn jedoch ein Passwort angegeben wird, dann wird Euch der Reviewserver mit jeder neuen SSH-Verbindung die Ihr später aufbauen werden nach diesem Passwort fragen. Sicherheit geht vor, aber kein Passwort anzugeben funktioniert später genauso gut.

In dem .ssh-Verzeichnis befinden sich nun zwei neue Dateien. Eine davon endet auf .pub. Diese müsst Ihr editieren und den Inhalt wie unter Punkt b) erklärt auf den Reviewserver kopieren.

f.) Für Spezialisten, die unter Punkt e.) einen eigenen Dateinamen angegeben haben

Standardmäßig wird für jede neu erstellte SSH-Verbindung immer der SSH-Key aus der Datei id_rsa verwendet. Um SSH mitzuteilen, dass es für die Verbindung zum TYPO3-Reviewserver einen anderen SSH-Key verwenden soll müsst Ihr eine config-Datei im .ssh-Verzeichnis erstellen. Der Inhalt könnt ungefähr so aussehen:

Host review.typo3.org
    HostName review.typo3.org
    User froemken
    IdentityFile ~/.ssh/typo3

Den Benutzernamen und den Pfad zum SSH-Key müsst Ihr natürlich anpassen. Als HostName könnt Ihr auch die IP-Adresse des Reviewservers angeben. Da diese sich gelegentlich ändern kann empfehle ich den Hostnamen wie oben einzutragen.

4.) Git konfigurieren

Beim Übertragen von Patches zum Reviewserver gibt es noch etwas das überprüft wird und zwar Eure Email-Adresse. Deshalb ist es sehr wichtig, dass die Email-Adresse Eures TYPO3-Benutzeraccounts unter Punkt 1.) exakt der angegebenen Email-Adresse in Eurer Git-Konfiguration entspricht.

Geht dazu in das Verzeichnis des TYPO3-Quellcodes und gebt mal folgenden Befehl ein:

ls -lisa

Wenn in der Ausgabe ganz oben ein paar Dateien zu sehen sind, die mit .git anfangen, dann seid Ihr richtig. Dann teilen wir Git mal mit wer wir sind und gebt die korrekte Email-Adresse an:

git config --local user.name "Dein Vor- und Nachname"
git config --local user.email "DeineEmailAdresseVomTYPO3Account"

Damit ist die Konfiguration nur für dieses eine Verzeichnis gesetzt. Wenn Ihr die absoluten TYPO3-Spezialisten seit und Euer ganzer Server nur TYPO3 kennt, für den empfiehlt es sich die Konfiguration global für ALLE Git-Verzeichnisse zu setzen:

git config --global user.name "Dein Vor- und Nachname"
git config --global user.email "DeineEmailAdresseVomTYPO3Account" 

Git Hook aktivieren

Ähnlich wie die Hooks in TYPO3, so kann auch Git bei bestimmten Prozessen durch weitere Funktionalität erweitert werden. Diese Hooks hat sich das TYPO3-Serverteam zu Nutze gemacht und beim Erstellen der Commit-Nachrichten (git commit -m "Commitnachricht") eingegriffen. Egal was Ihr für eine Commitnachricht angebt, dieser Hook fügt allen Nachrichten eine sogenannte Change-Id an. Dabei handelt es sich um den eindeutigen Schlüssel, der mit jedem Commit für eine Version in der Git-Versionierung erzeugt wird. Ich hatte den Schlüssel bereits in meinem vorherigen Tutorial erklärt: Abschnitt "Der Zweig (Branch)".

Gebt nun folgenden Befehl ein, um den Hook herunter zu laden und zu aktivieren:

curl -o .git/hooks/commit-msg "https://typo3.org/fileadmin/resources/git/commit-msg.txt" && chmod +x .git/hooks/commit-msg

Die Untermodule bei Git anmelden

Einige Extensions wie extbase und fluid wurden als sogenannte Submodules in die Versionierung des TYPO3-Quellcodes implementiert. Damit muss man als Entwickler nicht ständig den kompletten TYPO3-Quellcode updaten, sondern kann völlig autark in dem Verzeichnis dieser Submodule arbeiten. Trotz allem müssen diese Submodule bei Git angemeldet werden:

git submodule update --init

Den Hook für die Submodule einbinden

Wir haben vorhin einen Hook für Git angemeltet. Das Gleiche müssen wir nun auch für die Submodule machen, da diese, wie bereits erwählt, völlih autark arbeiten. Die wissen also noch nichts von irgendwelchen Hooks:

for module in .git/modules/typo3/sysext/*; do curl -o $module/hooks/commit-msg "https://typo3.org/fileadmin/resources/git/commit-msg.txt" && chmod +x $module/hooks/commit-msg; done

Es handelt sich bei diesem Befehl, um eine Schleife, die in jedes Verzeichnis der TYPO3-Systemextensions geht und überprüft, ob es sich dabei um eine Extension handelt, die als Submodule angelegt wurde. Wenn ja, dann wird dort der Hook eingebaut. Wenn Ihr also demnächst für das Projekt extbase programmieren solltet, werden alle Eure Commitnachrichten mit der zusätzlichen Change-Id versehen.

Sende die Patches zum Reviewserver

Ich hatte weiter oben erklärt, dass die TYPO3-Quellen vom TYPO3-Gitserver geladen werden: http://git.typo3.org. Wenn wir nun aber einen Patch senden (git push), würde dieser Patch direkt in den TYPO3-Quellen landen. Das hätte verheerende Folgen, wenn jeder DIREKT Zugriff auf die TYPO3-Quellen hätte. Jeder könnte tun und lassen, was er will. Das kann und darf nicht sein. Deshalb hat das TYPO3-Serverteam den Reviewserver aufgesetzt. Hier landen alle Patches und können von anderen Entwicklern überprüft und auch getestet werden. Erst wenn genügend Entwickler den Patch für OK befunden haben, wird dieser Patch vom Reviewserver aus in die TYPO3-Quellen gepushed.

Wir müssen Git also mitteilen, dass die Patches nicht auf dem Gitserver landen, sondern erstmal zum Reviewserver geschickt werden:

git config --global url."ssh://<username>@review.typo3.org:29418".pushInsteadOf git://git.typo3.org
git config --global branch.autosetuprebase remote

Wunderbar...Ihr habt es geschafft. Euer Gitverzeichnis ist nun fertig eingerichtet. Die TYPO3-Community freut sich auf Eure Patches.