J'ai vu une page wiki sur GitHub qui n'est pas ouverte à l'édition. Ensuite, j'ai bifurqué le projet, je l'ai édité sur "ma fin" et j'ai essayé de faire une pull request. Il s'avère que le wiki n'est pas dans le projet et qu'il n'y a pas de moyen de valider des modifications.

En dehors de l'envoi d'e-mail, y a-t-il un moyen de procéder si je veux suggérer une modification sur le wiki dans ce cas?

^{À ce stade, j'ai découvert ce qui semble être une alternative sous "Questions avec des titres similaires", mais je ne pouvais pas encore faire la pull request avec, et je ne suis donc pas sûr que les sous-modules soient un bon moyen pour cela. Je vois maintenant que je pourrais probablement le brancher d'une manière ou d'une autre ... Alors est-ce la voie à suivre?}

GitHub ne prend pas en charge les pull requests pour le référentiel wiki , seulement le référentiel principal (c'est un peu dommage, OMI, mais je peux le comprendre).

Voici une façon intéressante pour un projet de gérer les mises à jour de la communauté sur son wiki, tout en gardant un contrôle strict, comme pour le code source:

Mon flux de travail proposé est le suivant:

1. Créez manuellement un fork du wiki Taffy sur votre compte Github:
   • Créez un nouveau référentiel sur votre compte github. Appelons cela "Taffy-Wiki".
   • Clonez le dépôt wiki Taffy sur votre machine locale quelque part: git clone [email protected]:atuttle/Taffy.wiki.git
   • Supprimez la télécommande d'origine et ajoutez votre dépôt github en tant que nouvelle «origine» git remote rm originetgit remote add origin [email protected]:<YOUR_USERNAME>/Taffy-Wiki.git
2. Apportez les modifications proposées localement, puis poussez-les sur votre compte github: git push -u origin master('-u origin master' n'est requis que la première fois; ensuite, faites-le git push)
3. Envoyez un ticket au système de suivi des problèmes Taffy officiel pour me demander de revoir vos modifications et de les fusionner. Veillez à inclure un lien vers votre dépôt et à décrire ce que vous avez modifié.
4. Aller # 2

(De Comment vous pouvez contribuer à la documentation Taffy .)

Si c'était moi, je créerais un problème dans le référentiel principal (c'est-à-dire celui que vous avez forké) suggérant une mise à jour du wiki. Si les problèmes ne sont pas activés, les e-mails sont la seule autre option à laquelle je puisse penser.

J'ai adopté une approche différente à ce sujet, qui consiste à pousser exactement le même contenu à la fois dans le dépôt principal et dans le wiki. Ce ne sera pas du goût de tout le monde, mais Risk-First est principalement un wiki avec quelques pages Jekyll dans le référentiel principal.

Cela signifie que le processus pull request / fork fonctionne correctement. Cependant, après avoir fusionné une pull-request, je dois faire l'étape supplémentaire consistant à extraire mon dépôt local, puis à pousser à la fois le dépôt principal et le wiki, ce que git prend en charge avec plusieurs URL d'origine:

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

Pour ce faire, j'ai fusionné les commits des deux dépôts en suivant ceci:

Comment fusionner deux référentiels Git?

Et puis poussez vers les deux dépôts comme ceci:

Git - Pousser le code vers deux télécommandes

J'espère que cela aide quelqu'un.

Jusqu'à présent, nous avons trouvé la meilleure solution au problème sur https://devonfw.com :

1. Mettez votre documentation dans le référentiel git avec le code dans un dossier de documentation.
2. Prolongez votre build travis-ci avec un peu de magie qui met en scène tous les changements de ce dossier de documentation avec des transformations appliquées au wiki git. Voir le dernier lien d'exemple ci-dessous.
3. Considérez le wiki comme une vue en lecture seule de la documentation. Veuillez noter qu'avec github.com, vous pouvez toujours afficher et modifier directement les fichiers dans le dossier de documentation. Ainsi, vous pouvez toujours corriger les fautes de frappe dans le navigateur en quelques secondes (même en tant que PR sans autorisation sur le dépôt) - mais pas via le wiki.
4. Lorsqu'un contributeur forks, il a également la documentation avec le code. Il peut changer les deux dans un seul PR et tout est examiné dans le même processus, donc après la fusion, Code et Doc restent synchronisés. Vous avez toujours le meilleur UX pour lire la documentation dans le wiki avec la barre latérale, etc.

Comme nous sommes 100% OSS, nous aimons partager nos efforts acharnés pour arriver à cette excellente solution. Voici les liens à titre d'exemple:

• 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

Vous ne pouvez pas faire de pull request, mais vous pouvez ouvrir un problème, coller un lien vers votre page wiki et les laisser fusionner dans votre page wiki avec leur page wiki.

En bref:

Ils ont juste besoin de cloner votre dépôt de page wiki, (git clone YOUR_FORKED_REPO.wiki.git ), d'écraser tous vos commits wiki en un seul gros commit, puis de choisir ce gros commit écrasé sur leur dépôt. Cela apportera toutes les modifications de votre wiki dans leur wiki.

Instructions complètes:

(COPIÉ DE L'essentiel github de Larry Botha ICI: https://gist.github.com/larrybotha/10650410 ):

---------- DÉBUT DU COPY-PASTE À PARTIR DU GITHUB GIST CI-DESSUS ------------

Fusionner les modifications du wiki à partir d'un dépôt Github fourchu

Ceci est inspiré (ou fondamentalement copié) de Comment fusionner les changements de Wiki Github d'un référentiel à un autre , par Roman Ivanov, et sert à garantir que si quelque chose arrive à l'article original, les informations restent ici.

Terminologie

OREPO : repo original - le repo créé ou maintenu par le propriétaire

FREPO : le repo forké qui a vraisemblablement mis à jour son wiki, pas encore sur l' OREPO

Contribuant

Si vous souhaitez contribuer au wiki d'un dépôt que vous avez forké, procédez comme suit:

• fourchette le repo
• clonez uniquement le wiki sur votre machine: $ g clone [FREPO].wiki.git
• apporter des modifications à votre dépôt wiki local forké
• transmettre vos modifications à GitHub

Une fois que vous êtes prêt à informer l'auteur que vous avez des modifications, procédez comme suit:

• ouvrir un numéro sur OREPO
• fournir un lien direct vers le dépôt git de votre wiki pour faciliter la fusion: par exemple [ FREPO ] .wiki.git

Fusion des modifications

En tant que propriétaire d' OREPO , vous avez maintenant reçu un message indiquant qu'il y a des mises à jour de votre wiki sur le FREPO de quelqu'un d'autre .

Si les modifications du wiki proviennent du dernier wiki OREPO , vous pouvez effectuer les opérations suivantes:

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

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

$ git push origin master

Si le wiki OREPO est en avance sur l'origine de FREPO , procédez comme suit:

$ 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

---------- FIN DU COPY-PASTE DU GITHUB GIST CI-DESSUS ------------

Si vous êtes d'accord pour avoir un document d'une seule page (en fait je l'aime plus), vous pouvez détourner le README.MD et y mettre le contenu du wiki.

Non seulement il sera suivi dans le cadre du référentiel normal, mais il sera également affiché sur la page d'accueil.

Il peut être fait pour commencer par une référence rapide, puis entrer dans une description / des instructions plus détaillées, de sorte que les utilisateurs réguliers obtiennent d'abord les informations les plus génériques.