Änderung einreichen

Sie haben eine Änderung fertig und möchten sie zurückgeben.

Es gibt zwei Wege, und welcher gilt, hängt vom Umfang ab. Eine einzelne Textdatei lässt sich unmittelbar im Repository-Bildschirm anlegen oder bearbeiten und festschreiben. Alles, was mehrere Dateien betrifft, binär ist oder lokal gebaut und geprüft werden muss, geht über den Git-Endpunkt zurück.

Die beiden Wege verlangen nicht dieselbe Berechtigung, und das ist der häufigste Grund, warum der eine geht und der andere nicht:

Ansehen und Beziehen genügen für keinen der beiden. Welche Stufe eine Einbindung an wen vergibt, steht unter Repository clonen; die Stufe vorschlagen vergibt dort keine der Vorlagen, sie entsteht nur aus einer eigens geschriebenen Regel.

Weg 1 — eine einzelne Textdatei im Browser

1. Öffnen Sie das Repository aus Repositories.
2. Prüfen Sie im Kopf, auf welchem Branch Sie stehen — dorthin geht der Commit. Ein anderer lässt sich dort auswählen.
3. Eine vorhandene Datei: im Baum öffnen, Inhalt ändern, mit einer Beschreibung festschreiben. Siehe Datei bearbeiten.
4. Eine neue Datei: Neue Datei im Kopf, Pfad und Inhalt eintragen, festschreiben. Liegt unter dem Pfad schon etwas, wird abgelehnt und nichts geschrieben. Siehe Neue Datei anlegen.
5. Reicht Ihre Berechtigung nicht, erscheinen diese Möglichkeiten nicht.

Binärdateien — Bilder, Archive, Schriften — gehen nicht über diesen Weg. Dafür gilt Weg 2.

Weg 2 — lokal, über Git

1. Prüfen Sie Ihre Änderung nach den fünf Abnahmeschritten aus Entwicklungsumgebung einrichten.
2. Lassen Sie die Stilprüfung laufen und beheben Sie maschinell behebbare Befunde:

composer cs
composer cbf

1. Ziehen Sie das Manifestdatum des geänderten Pakets nach. Es ist das Signal, an dem eine Aktualisierung überhaupt erkannt wird; bleibt es stehen, meldet sich das Paket als der Stand von zuvor.
2. Schreiben Sie den Commit-Text so, dass er sein Arbeitselement in einer eigenen Schlusszeile nennt. Ohne diese Zeile entsteht kein Bezug zwischen Arbeitselement und Code, und es gibt keine Warnung darüber.
3. Geben Sie zurück:

git push

Auf der Stufe vorschlagen nimmt der Endpunkt nur Branches unter Ihrem eigenen Präfix an und weist alles andere mit push refused: outside_own_prefix ab. Den Branchnamen und die beiden dafür nötigen Befehle nennt Repository clonen.

Ein abgelehnter push ist meist eine Berechtigungsfrage, kein Fehler. Steht im Bereich Dieses Repository beziehen der Hinweis auf reinen Lesezugriff, wird ein push abgewiesen; der Weg führt dann über Zugriff anfordern. Erscheint der Hinweis nicht und wird trotzdem abgewiesen, liegt es am Branchnamen und nicht an der Berechtigung — die Meldung des Endpunkts unterscheidet die beiden Fälle.

Nicht festgelegt: Branch, Prüfung, Übernahme. Für dieses Vorhaben besteht kein verbindliches Branching-Modell, kein Review-Verfahren und keine Merge-Regel. Diese Anleitung erfindet keine; sie beschreibt, was die Plattform leistet. Welcher Branch im Einzelfall gilt und wer prüft, klären Sie mit der Projektverantwortung. Der vollständige Stand steht unter Stand der Beitragsregeln.

Kein Änderungsprotokoll als Pflicht. Von den eigenen Paketen führt eines ein Änderungsprotokoll; eine durchgängige Konvention besteht nicht.

Sprachen nicht vergessen. Ändert eine Anpassung Oberflächentexte, gehören sie in alle fünf Sprachdateien. Ein fehlender Eintrag zeigt keinen Fehler, sondern den nackten Schlüsselnamen.

• Entwicklungsumgebung einrichten
• Stand der Beitragsregeln
• Repository clonen
• Eine Datei im Browser bearbeiten — der erste Weg im Detail
• Eine neue Datei im Browser anlegen — derselbe Weg für eine Datei, die es noch nicht gibt