samykabu/github-wiki-publish

GitHub Wiki Veröffentlichen

Veröffentlichen Sie das angeforderte Material im bestehenden Wiki des Repositorys. Halten Sie die Inhaltserstellung von der Veröffentlichung getrennt: Verwenden Sie die bereitgestellten Seiten, Berichte und Assets und passen Sie Links und Navigation nach Bedarf an. Befolgen Sie die Regeln des Zielprojekts, ohne Konventionen aus einem anderen Projekt zu importieren.

Ziel und Umfang festlegen

• Ermitteln Sie den GitHub-Host, das Repository, die Wiki-URL, die Quelldateien und die beabsichtigten Seitennamen aus der Anfrage und dem Repository-Kontext. Fragen Sie nur bei ungeklärten Entscheidungen nach, die die Veröffentlichung wesentlich ändern.
• Unterscheiden Sie Vorbereitung von Veröffentlichung. Eine explizite Aufforderung zur Veröffentlichung autorisiert das genannte Wiki-Update; fragen Sie nicht erneut für dieselbe Aktion nach. Eine Anfrage für einen Entwurf oder eine Bewertung allein autorisiert keinen Push.
• Erkunden Sie zuerst relevante Connector-Fähigkeiten. Wenn diese Wiki-Inhalte und Assets nicht angemessen verwalten können, verwenden Sie das separate Git-Repository des Wikis. Erläutern Sie den Fallback kurz. Die üblichen Repository-Inhalts-APIs adressieren nicht das Wiki-Repository.
• Überprüfen Sie den Zugriff mit der vorhandenen authentifizierten Verbindung oder Git-Anmeldeinformationen. Betten Sie niemals Anmeldeinformationen in URLs, Seiten oder aufbewahrte Nachweise ein. Ein nicht authentifizierter 404 beweist nicht, dass ein privates Wiki fehlt.
• Wenn kein Wiki-Git-Repository existiert, prüfen Sie, ob das Wiki deaktiviert ist oder seine erste Seite über GitHub erstellt werden muss. Aktivieren Sie keine Repository-Funktionen und ändern Sie keinen Zugriff als Nebeneffekt. Verwenden Sie nach Möglichkeit eine autorisierte Ersterstellung einer Seite; melden Sie andernfalls die fehlende Voraussetzung.

Eine abgegrenzte Aktualisierung vorbereiten

Lesen Sie für die Git-Veröffentlichung das Git-Verfahren. Verwenden Sie einen frischen temporären Klon, entdecken Sie seinen tatsächlichen Standard-Branch und lesen Sie die vorhandenen Zielseiten, Home und Seitenleiste, bevor Sie schreiben.

• Ordnen Sie jede Quelldatei einer Zielseite oder einem Asset zu. Erhalten Sie nicht zusammenhängende Seiten, manuell verfasste Abschnitte und die Navigation. Eine fehlende Quelldatei ist keine Anweisung zum Löschen. Ersetzen Sie eine gesamte Seite nur, wenn sie zur angeforderten Aktualisierung gehört; verwenden Sie eine enge Bearbeitung für gemeinsame Home-/Seitenleisteninhalte. Behalten Sie vorhandene Links bei und vermeiden Sie doppelte Navigationseinträge bei wiederholten Durchläufen.
• Lesen und schreiben Sie Text explizit als UTF-8. Kopieren Sie binäre Assets Byte für Byte. Reparieren Sie nicht stillschweigend Quellfakten oder aktualisieren Sie einen Bericht aus einem anderen Datensatz. Bewahren Sie sein tatsächliches Datum, seine Herkunft und seine Einschränkungen; verwenden Sie den entsprechenden vorgelagerten Generator nur, wenn eine Neugenerierung im Umfang enthalten ist.
• Schreiben Sie Links für das tatsächliche Wiki-Ziel um. Repository-relative Links können nach dem Verschieben einer Seite brechen. Kopieren Sie referenzierte Assets oder verlinken Sie auf eine zugängliche Repository-Revision; hinterlassen Sie keine lokalen Pfade, unveröffentlichten Branch-Links oder nicht zugängliche externe Ressourcen.
• Das Wiki zeigt den Dateinamen der Seite als Titel an, daher wird eine Seite, die mit ihrer eigenen H1-Überschrift beginnt, zweimal angezeigt. Entfernen Sie diese H1 und benennen Sie die Seite nach ihr; behalten Sie eine H1 nur bei, wenn sie sich absichtlich vom Seitennamen unterscheidet (z. B. Home); aktualisieren Sie die Navigation auf die abgeleiteten Namen. Home wird unter /wiki bereitgestellt, daher werden seine relativen Links außerhalb des Wikis aufgelöst: Verwenden Sie absolute Wiki-URLs für Bilder, Seitenlinks und die Seitenleiste.
• Verwenden Sie unterstützte Inline-Bilder mit sinnvollen Alternativtexten. Stellen Sie für einen HTML-Bericht oder ein animiertes/interaktives Diagramm eine nützliche statische Vorschau und Links zum ursprünglichen Artefakt bereit, wenn das Wiki es nicht rendern kann. Beschreiben Sie herunterladbares HTML nicht als eine im Wiki bereitgestellte Anwendung. Befolgen Sie projektspezifische Diagrammwerkzeuge, wenn die Erstellung neuer Grafiken im Umfang enthalten ist; von dieser Fähigkeit ist kein bestimmter Generator erforderlich.
• Überprüfen Sie lokale Links und Assets, repräsentativen Nicht-ASCII-Text und die genauen geänderten Pfade. Untersuchen Sie das endgültige Diff auf unbeabsichtigte Löschungen, überschriebene Inhalte, Anmeldeinformationen und Generierungsreste. Behalten Sie temporäre Klone und lokale Nachweise außerhalb des Anwendungsrepositorys, es sei denn, der Benutzer oder das Projekt erfordert, dass die Quellen dort aufbewahrt werden.

Veröffentlichen und überprüfen

Wenden Sie die Veröffentlichung nur innerhalb der vorhandenen Autorisierung des Benutzers an. Ein Wiki-Update autorisiert weder das Pushen eines Anwendungs-Branches, das Ändern von Issues, das Bereitstellen einer Website, das Planen einer Synchronisation noch das Installieren von CI.

• Committen Sie nur die beabsichtigten Wiki-Pfade, holen Sie dann gleichzeitige Änderungen ab und gleichen Sie diese aus, wie im Git-Verfahren beschrieben. Pushen Sie normal zum entdeckten Standard-Branch des Wikis. Verwenden Sie niemals Force-Push, um einen anderen Schreiber zu überwinden.
• Bei Zurückweisung einmal abholen und inspizieren. Integrieren Sie kompatible Bearbeitungen und überprüfen Sie das vollständige Diff erneut. Tritt derselbe Konflikt erneut auf, kann die Absicht nicht geklärt werden oder der Zugriff schlägt fehl, stoppen Sie Wiederholungen und behalten Sie den wiederherstellbaren Klon mit einer genauen Blockierungsmeldung. Löschen Sie ihn bei einem Fehler nicht.
• Überprüfen Sie den veröffentlichten Commit gegen das Live-Remote. Ein sauberer Arbeitsbaum allein beweist nicht, dass lokale Commits gepusht wurden.
• Inspizieren Sie die tatsächlich bereitgestellte Seite nach Möglichkeit über einen authentifizierten Browser: Seitentext, repräsentative Unicode-Zeichen, Navigation, Links, Bilderladung und Lesbarkeit. Vergleichen Sie bei Diagrammen das gerenderte Ergebnis mit den Quellfakten. Überprüfen Sie ein Bild in voller Größe, wenn seine Inline-Vorschau Beschriftungen verdeckt. Korrigieren Sie beobachtete Mängel innerhalb des Umfangs und überprüfen Sie die betroffenen Inhalte erneut.
• Wenn eine authentifizierte gerenderte Überprüfung nicht verfügbar ist, melden Sie die Veröffentlichung und die Remote-Überprüfung getrennt von der nicht ausgeführten Browser-Prüfung. Behaupten Sie keinen bestandenen Rendertest basierend auf lokalen Dateien, einer HTTP-Antwort oder einem erfolgreichen Push.

Melden Sie die Seiten-URL, die veröffentlichte Revision, die wesentlichen Änderungen, die durchgeführten Prüfungen und alle ungelösten Einschränkungen. Halten Sie Wiederherstellungspfade bereit, wenn Arbeiten unveröffentlicht bleiben. Fügen Sie kein neues Genehmigungsgate, kein Inhaltsschema, keinen Projektlebenszyklus und kein Testregime hinzu.