Ich habe eine Wiki-Seite auf gesehen GitHub die nicht zur Bearbeitung geöffnet ist. Dann habe ich das Projekt gegabelt, es auf “meiner Seite” bearbeitet und versucht, eine Pull-Anfrage zu stellen. Es stellt sich heraus, die wiki befindet sich nicht im Projekt, und es gibt keine Möglichkeit, Änderungen daran zu übernehmen.

Gibt es eine andere Möglichkeit als E-Mail, um in diesem Fall eine Änderung im Wiki vorzuschlagen?

^{An dieser Stelle habe ich unter “Fragen mit ähnlichen Titeln” herausgefunden, was wie eine Alternative aussieht, aber ich konnte die Pull-Anforderung damit noch nicht 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-Requests für das Wiki-Repositorynur das Haupt-Repository (das ist ein bisschen schade, IMO, aber ich kann es verstehen).

Hier ist eine interessante Art und Weise, wie ein Projekt Community-Updates für sein Wiki verwaltet und gleichzeitig eine strenge Kontrolle über den Quellcode behält:

Mein vorgeschlagener Workflow ist dieser:

1. Erstellen Sie manuell einen Fork des Taffy-Wikis auf Ihrem Github-Konto:
   • Erstellen Sie ein neues Repository auf 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-Repository als neuen “Origin” hinzu. git remote rm origin und git 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’ nur beim ersten Mal erforderlich; danach einfach tun git push)
3. Senden Sie ein Ticket an den offiziellen Taffy Issue Tracker und bitten Sie mich, Ihre Änderungen zu überprüfen und sie zusammenzuführen. Stellen Sie sicher, dass Sie einen Link zu Ihrem Repo einfügen und beschreiben, was Sie geändert haben.
4. Gehe zu Nr. 2

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

Wenn ich es wäre, würde ich ein Problem im Haupt-Repository erstellen (d. h. in dem von Ihnen geforkten), das eine Aktualisierung des Wikis vorschlagen würde. Wenn Probleme nicht aktiviert sind, dann ist E-Mail die einzige andere Option, die mir einfällt.

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

1. Legen Sie Ihre Dokumentation zusammen mit dem Code in einem Dokumentationsordner im Git-Repository ab.
2. Erweitern Sie Ihre Travis C.I 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 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 innerhalb des Browsers immer noch innerhalb von Sekunden beheben (sogar als PR ohne Berechtigungen auf dem Repo) – nur nicht über das Wiki.
4. Wenn ein Mitwirkender abzweigt, hat er/sie auch die Dokumentation mit dem Code. Er/sie kann beide in einem PR ändern und alles wird im selben Prozess überprüft, sodass Code und Dokumentation nach dem Zusammenführen synchron bleiben. Trotzdem hast du das Schönere UX zum Lesen von Dokumentationen im Wiki mit Sidebar etc.

Da wir 100% sind OSS, wir lieben es, unsere harten Bemühungen zu teilen, um zu dieser großartigen Lösung zu kommen. Hier die Links als Beispiel:

• https://devonfw.com/website/pages/docs/master-devon4j.asciidoc_introduction.html
• Die Architektur
• devon4j, Die Architektur
• devonfw für Java 3.2.0 (2019)
• devon4j/.travis.yml

Ich habe einen anderen Ansatz gewählt, nämlich genau denselben Inhalt sowohl in das Hauptrepo als auch in das Wiki zu schieben. Das wird nicht jedermanns Geschmack sein, aber Risiko zuerst ist hauptsächlich ein Wiki mit ein paar Jekyll Seiten im Hauptrepository.

Das bedeutet, dass der Pull-Request/Fork-Prozess gut funktioniert. Nach dem Zusammenführen einer Pull-Anfrage muss ich jedoch den zusätzlichen Schritt ausführen, in mein lokales Repository zu ziehen und dann sowohl in das Haupt-Repository als auch in das Wiki zu pushen, was Git mit mehreren Ursprungs-URLs gut 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 Repositories wie folgt zusammengeführt:

Wie führt man zwei Git-Repositories zusammen?

Und dann wie folgt auf beide Repositories pushen:

Git – Code auf zwei Fernbedienungen übertragen

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

Zusamenfassend:

Sie müssen nur Ihr Wiki-Seiten-Repository klonen (git clone YOUR_FORKED_REPO.wiki.git), alle Ihre Wiki-Commits in einem großen Commit zusammenzufassen, und dann dieses große gequetschte Commit in ihrem Repository herauszupicken. Dadurch werden alle Ihre Wiki-Änderungen in ihr Wiki übernommen.

Vollständige Anleitung:

(Abkopiert Larry Bothas GitHub-Grundlagen hier: Führen Sie Wiki-Änderungen aus einem geforkten GitHub-Repository zusammen):

Wiki-Änderungen aus einem gegabelten GitHub-Repo zusammenführen

Dies ist inspiriert (oder im Grunde kopiert) von So führen Sie GitHub-Wiki-Änderungen von einem Repository in ein anderes zusammenvon Roman Ivanov, und dient dazu, dass die Informationen hier schön und sicher bleiben, sollte etwas mit dem Originalartikel passieren.

Terminologie

OREPO: ursprüngliches Repo – das vom Eigentümer erstellte oder verwaltete Repo

FREPO: das gegabelte Repo, das vermutlich Updates für sein Wiki enthält, noch nicht auf dem OREPO

Beitragen

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

• Forken Sie das Repo
• Klonen Sie nur das Wiki auf Ihren Rechner:
  $ g clone [FREPO].wiki.git
• Nehmen Sie Änderungen an Ihrem lokalen Fork-Wiki-Repo vor
• pushen Sie Ihre Änderungen auf GitHub

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

• Eröffnen Sie ein Problem auf OREPO
• Stellen Sie einen direkten Link zum Git-Repo Ihres Wikis bereit, um das Zusammenführen zu erleichtern: dh [FREPO].wiki.git

Zusammenführen von Änderungen

Als Eigentümer von OREPOhaben Sie jetzt eine Nachricht erhalten, dass es Updates für Ihr Wiki auf dem Wiki von jemand anderem gibt FREPO.

Wenn Wiki-Änderungen von den neuesten gegabelt werden OREPO Wiki 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 OREPO Wiki ist wo voraus FREPO gegabelt, gehen Sie wie folgt vor:

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

# Check out 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 - How can I make a pull request for a wiki page on GitHub?"
$ git checkout master

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

GitHub unterstützt dies jetzt und Sie können Details finden unter Hinzufügen oder Bearbeiten von Wiki-Seiten.

Es wird jetzt als “normales” Repository behandelt, mit Branches, Pull-AnfragenZusagen usw.

Wenn Sie ein Dokument mit einer einzigen Seite haben möchten (ich mag es eigentlich mehr), können Sie das entführen README.MD und 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 kurzen Referenz zu beginnen und dann in eine detailliertere Beschreibung/Anweisungen überzugehen, so dass die normalen Benutzer zuerst die allgemeineren Informationen finden.