Ich habe auf GitHub eine Wiki-Seite gesehen , die nicht zum Bearbeiten geöffnet ist. Dann gabelte ich das Projekt, bearbeitete es auf "mein Ende" und versuchte eine Pull-Anfrage zu machen. Es stellt sich heraus, dass das Wiki nicht im Projekt enthalten ist und es keine Möglichkeit gibt, Änderungen daran vorzunehmen.

Gibt es außer dem E-Mail-Versand eine Möglichkeit, fortzufahren, wenn ich in diesem Fall eine Änderung im Wiki vorschlagen möchte?

^{Zu diesem Zeitpunkt habe ich unter "Fragen mit ähnlichen Titeln" herausgefunden, was als Alternative erscheint , aber ich konnte die Pull-Anfrage noch nicht damit ausführen, und daher bin ich mir nicht sicher, ob Submodule ein guter Weg für diesen Zweck sind. Ich sehe jetzt, dass ich es wahrscheinlich irgendwie verzweigen könnte ... Also ist das der richtige Weg?}

GitHub unterstützt keine Pull-Anfragen für das Wiki-Repository , nur das Haupt-Repository (das ist ein bisschen schade, IMO, aber ich kann es verstehen).

Hier ist eine interessante Möglichkeit, wie ein Projekt Community-Updates für sein Wiki verwaltet und dabei die Kontrolle über den Quellcode behält:

Mein vorgeschlagener Workflow ist folgender:

1. Erstellen Sie manuell eine Abzweigung des Taffy-Wikis in Ihrem Github-Konto:
   • Erstellen Sie ein neues Repository in Ihrem Github-Konto. Nennen wir es "Taffy-Wiki".
   • Klonen Sie das Taffy-Wiki-Repo irgendwo auf Ihren lokalen Computer: git clone [email protected]:atuttle/Taffy.wiki.git
   • Entfernen Sie die ursprüngliche "Origin" -Fernbedienung und fügen Sie Ihr Github-Repo als neuen "Origin" git remote rm originund hinzugit remote add origin [email protected]:<YOUR_USERNAME>/Taffy-Wiki.git
2. Nehmen Sie Ihre vorgeschlagenen Änderungen lokal vor und übertragen Sie sie dann auf Ihr Github-Konto: git push -u origin master('-u origin master' ist nur beim ersten Mal erforderlich; danach einfach git push)
3. Senden Sie ein Ticket an den offiziellen Taffy Issue Tracker und fordern Sie mich auf, Ihre Änderungen zu überprüfen und zusammenzuführen. Bitte fügen Sie einen Link zu Ihrem Repo hinzu und beschreiben Sie, was Sie geändert haben.
4. Gehe zu # 2

(Von Wie Sie zur Taffy-Dokumentation beitragen können .)

Wenn ich es wäre, würde ich ein Problem im Haupt-Repository erstellen (dh das, das Sie gegabelt haben), das ein Update des Wikis vorschlägt. Wenn Probleme nicht aktiviert sind, ist E-Mail die einzige andere Option, die mir in den Sinn kommt.

Ich habe einen anderen Ansatz gewählt, nämlich genau den gleichen Inhalt sowohl in das Haupt-Repo als auch in das Wiki zu übertragen. Dies ist nicht jedermanns Sache, aber Risk-First ist hauptsächlich ein Wiki mit einigen Jekyll-Seiten im Haupt-Repo.

Dies bedeutet, dass der Pull-Request / Fork-Prozess einwandfrei funktioniert. Nach dem Zusammenführen einer Pull-Anfrage muss ich jedoch den zusätzlichen Schritt ausführen, um zu meinem lokalen Repo zu ziehen und dann sowohl zum Haupt-Repo als auch zum Wiki zu wechseln, das Git mit URLs mit mehreren Ursprüngen unterstützt:

localhost:website robmoffat$ git remote show origin
* remote origin
  Fetch URL: [email protected]:risk-first/website.git
  Push  URL: [email protected]:risk-first/website.wiki.git
  Push  URL: [email protected]:risk-first/website.git
  HEAD branch: master

Um dies zu erreichen, habe ich die Commits aus beiden Repos wie folgt zusammengeführt:

Wie fügst du zwei Git-Repositorys zusammen?

Und dann auf beide Repos wie folgt drücken:

Git - Code auf zwei Fernbedienungen übertragen

Hoffe das hilft jemandem.

Die beste Lösung für das Problem haben wir bisher unter https://devonfw.com gefunden :

1. Legen Sie Ihre Dokumentation zusammen mit dem Code in einem Dokumentationsordner im Git-Repository ab.
2. Erweitern Sie Ihren travis-ci-Build mit etwas Magie, die alle Änderungen aus diesem Dokumentationsordner mit Transformationen inszeniert, die auf das Wiki-Git angewendet werden. Siehe letzten Beispiellink unten.
3. Betrachten Sie das Wiki als schreibgeschützte Ansicht in der Dokumentation. Bitte beachten Sie, dass Sie mit github.com die Dateien im Dokumentationsordner weiterhin anzeigen und direkt bearbeiten können. So können Sie Tippfehler im Browser innerhalb von Sekunden beheben (auch als PR ohne Berechtigungen für das Repo) - nur nicht über das Wiki.
4. Wenn sich ein Mitwirkender teilt, hat er auch die Dokumentation mit dem Code. Er kann beide in einem PR ändern und alle werden im selben Prozess überprüft, sodass Code und Doc nach dem Zusammenführen synchron bleiben. Trotzdem haben Sie die schönere UX zum Lesen der Dokumentation im Wiki mit Seitenleiste usw.

Da wir zu 100% OSS sind, teilen wir gerne unsere Anstrengungen, um zu dieser großartigen Lösung zu gelangen. Hier sind die Links als Beispiel:

• https://devonfw.com/website/pages/docs/master-devon4j.asciidoc_introduction.html
• https://github.com/devonfw/devon4j/wiki/architecture
• https://github.com/devonfw/devon4j/blob/develop/documentation/architecture.asciidoc#architecture
• https://repo1.maven.org/maven2/com/devonfw/java/doc/devon4j-doc/3.2.0/devon4j-doc-3.2.0.pdf
• https://github.com/devonfw/devon4j/blob/develop/.travis.yml

Sie können keine Pull-Anfrage stellen, aber Sie können ein Problem öffnen, einen Link zu Ihrer Wiki-Seite einfügen und sie in Ihrer Wiki-Seite mit ihrer Wiki-Seite zusammenführen lassen.

Zusamenfassend:

Sie müssen nur Ihr Wiki-Seiten-Repo ( git clone YOUR_FORKED_REPO.wiki.git) klonen , alle Ihre Wiki-Commits zu einem großen Commit zusammenfassen und dann dieses große Squashed-Commit für ihr Repo auswählen. Dadurch werden alle Ihre Wiki-Änderungen in das Wiki übernommen.

Vollständige Anleitung:

(KOPIERT VON Larry Bothas Github-Inhalt HIER: https://gist.github.com/larrybotha/10650410 ):

---------- START DER KOPIERPASTE AUS DEM OBEN GITHUB GIST ------------

Zusammenführen von Wiki-Änderungen aus einem gegabelten Github-Repo

Dies ist inspiriert (oder im Grunde genommen kopiert) von Roman Ivanov, wie Änderungen im Github-Wiki von einem Repository zum anderen zusammengeführt werden, und dient dazu, sicherzustellen, dass die Informationen hier nett und sicher bleiben, falls etwas mit dem Originalartikel passiert.

Terminologie

OREPO : Original-Repo - das vom Eigentümer erstellte oder verwaltete Repo

FREPO : Das gegabelte Repo, dessen Wiki vermutlich aktualisiert wurde, noch nicht auf dem OREPO

Mitwirken

Wenn Sie zum Wiki eines von Ihnen gespaltenen Repos beitragen möchten, gehen Sie wie folgt vor:

• Gabel das Repo
• Klonen Sie nur das Wiki auf Ihren Computer: $ g clone [FREPO].wiki.git
• Nehmen Sie Änderungen an Ihrem lokalen gegabelten Wiki-Repo vor
• Übertragen Sie Ihre Änderungen auf GitHub

Wenn Sie bereit sind, dem Autor mitzuteilen, dass Sie Änderungen vorgenommen haben, gehen Sie wie folgt vor:

• Öffnen Sie eine Ausgabe auf OREPO
• Stellen Sie einen direkten Link zum Git-Repo Ihres Wikis bereit, um das Zusammenführen zu vereinfachen: dh [ FREPO ] .wiki.git

Änderungen zusammenführen

Als Eigentümer von OREPO haben Sie jetzt die Nachricht erhalten, dass Ihr Wiki auf dem FREPO eines anderen aktualisiert wird .

Wenn Wiki-Änderungen vom neuesten OREPO- Wiki übernommen wurden, können Sie Folgendes tun:

$ git clone [OREPO].wiki.git
$ cd [OREPO].wiki.git

# squashing all FREPO changes
$ git pull [FREPO].wiki.git master

$ git push origin master

Wenn das OREPO- Wiki vor dem Ausgangspunkt von FREPO liegt , gehen Sie wie folgt vor:

$ git clone [OREPO].wiki.git
$ cd [OREPO].wiki.git
$ git fetch [FREPO] master:[FREPO-branch]
$ git checkout [FREPO-branch]

#checkout to last OREPO commit
$ git reset --hard [last-OREPO-commit-hash]

# do massive squash of all FREPO changes
$ git merge --squash HEAD@{1}
$ git commit -m "Wiki update from FREPO - [description]"
$ git checkout master

# cherry-pick newly squashed commit
$ git cherry-pick [OREPO-newly-squashed-commit]
$ git push

---------- ENDE DER KOPIERPASTE AUS DEM OBEN GITHUB GIST ------------

Wenn Sie in Ordnung sind, ein einseitiges Dokument zu haben (ich mag es eigentlich mehr), können Sie das entführen README.MDund den Inhalt des Wikis dort ablegen.

Es wird nicht nur als Teil des normalen Repositorys verfolgt, sondern auch auf der Startseite angezeigt.

Es kann gemacht werden, mit einer Kurzreferenz zu beginnen und dann zu detaillierteren Beschreibungen / Anweisungen zu gelangen, so dass die regulären Benutzer zuerst die allgemeineren Informationen treffen.