Eine Datei aus dem Wiki bearbeiten und committen

Ausgangslage

Eine einzelne Datei in einem gemounteten Repository ist zu korrigieren, etwa ein Tippfehler in der README oder ein Wert in einer Konfigurationsdatei — und zwar ohne git-Client und ohne lokale Kopie.

Lösungsüberblick

Der Repository-Browser bietet einen Editor für einzelne Dateien. Er verlangt Schreibrecht (Level 8) auf dem Mount-Namespace; bei niedrigerem Level gibt es die Schaltfläche nicht.

Der Commit greift gegen die Fassung, die der Editor geladen hat. Hat sich die Datei inzwischen geändert, weist der Server den Commit zurück, statt die fremde Änderung still zu überschreiben.

Bei Azure DevOps reicht der Service-Account den Commit ein. pushedBy ist dort deshalb der Service-Account, der Commit-Author bleibt der Wiki-Benutzer; Name und E-Mail-Adresse stammen aus seinem Profil.

Durchführung

Öffnen Sie das Repository. Der kürzeste Weg führt über die Liste Repositories oder über die Repository-Seite Ihres Projekts; ebenso funktioniert eine Wiki-Seite mit der Marke {{wk:adogit>…}}. Den ganzen Weg von vorn beschreibt die Anleitung.
Prüfen Sie im Kopf, auf welchem Branch Sie stehen — dorthin geht der Commit. Im Arbeitsbereich wählen Sie einen anderen über die Auswahl Branch.
Suchen Sie die Datei im Baum. Haben Sie Schreibrecht, steht daneben die Schaltfläche Bearbeiten.
Wählen Sie Bearbeiten. Es öffnet sich der Editor mit den Feldern Dateiinhalt und Commit-Nachricht.
Bearbeiten Sie den Inhalt und tragen Sie eine Commit-Nachricht ein.
Wählen Sie Commit. Die Änderung geht unmittelbar auf den Branch, den der Kopf des Browsers zeigt.

Der Server antwortet mit einem von fünf Zuständen.

Zustand	Bedeutung	Was Sie tun
`ok`	der Commit ist angewandt	nichts; der Baum zeigt den neuen Stand
`denied`	auf dem Mount-Namespace fehlt Ihnen das Schreibrecht	bitten Sie um einen höheren Tier des Mounts
`conflict`	die Datei hat sich während der Bearbeitung geändert	Editor schließen, Datei erneut öffnen und die Änderung wiederholen
`rejected`	Pfad, Branch oder Inhalt hat die Prüfung nicht bestanden	Pfad oder Branch berichtigen
`error`	Anmeldung, Übertragung oder unerwartete Antwort des Servers	siehe Diagnose

Neuer Branch oder Tag

Gehört die Änderung nicht auf den gezeigten Branch, legen Sie einen neuen an. Im Kopf des Browsers steht die Schaltfläche Neuer Branch/Tag, sichtbar nur bei Schreibrecht.

Wählen Sie Neuer Branch/Tag.
Wählen Sie die Art (Branch oder Tag), tragen Sie den neuen Namen ein und bestätigen Sie.
Der neue Branch oder Tag entsteht an der Spitze des Branches, an den der Browser geheftet ist.

Ein vorhandener Name wird nicht überschrieben; der Server antwortet mit dem Zustand conflict.

Auf den neuen Branch wechseln Sie im Arbeitsbereich über die Auswahl Branch oder über den Reiter Branches. Auf einer eingebetteten Seite steht diese Auswahl nicht zur Verfügung; dort tragen Sie den Namen als viertes Feld in die Marke ein:

{{wk:adogit>wvds:DokuWiki-Plugins:wkdoadogit:users/hmustermann/korrektur}}

Hinweise

Eingebettet und eigenständig unterscheiden sich. Der Arbeitsbereich (do=wkdoadogit_repo) hat die Reiter Code, Branches und Tags sowie die Auswahl für Repository und Branch. Die eingebettete Marke auf einer Wiki-Seite hat das nicht: dort bestimmt die Marke, was gezeigt wird.
Eine Datei, die es noch nicht gibt, legen Sie nicht hier an. Dafür gibt es Neue Datei; siehe Eine neue Datei im Browser anlegen. Der Unterschied ist die Absicherung: der Editor prüft gegen die geladene Fassung, das Anlegen prüft, dass der Pfad frei ist.
Der Editor bearbeitet eine Datei auf einmal. Für mehrere Dateien in einem Commit nehmen Sie git clone; siehe Repository klonen.
Ein persönliches Token ist hier nicht nötig. Innerhalb des Wikis entscheiden die DokuWiki-Rechte; das Token ist für externe git-Clients gedacht.
Jeder Aufruf wird erneut geprüft. Bearbeiten und Committen laufen über Aufrufe, die das Recht serverseitig prüfen; die Schaltfläche ist Bequemlichkeit, keine Erlaubnis.
Binäre und zu große Dateien öffnet der Editor nicht. Statt des Inhalts liefert er einen Zustand.
Einen Teilerfolg gibt es nicht. Scheitert der Commit, hat sich im Repository nichts geändert.