Ho visto una pagina wiki su GitHub che non è aperta per l'editing. Quindi ho modificato il progetto, l'ho modificato su "my end" e ho provato a fare una richiesta pull. Si scopre che la wiki non è nel progetto e non esiste un modo per eseguire il commit delle modifiche.

Oltre all'e-mail, c'è un modo per procedere se voglio suggerire una modifica sul wiki in questo caso?

^{A questo punto ho scoperto quella che sembra un'alternativa sotto "Domande con titoli simili", ma non ho ancora potuto fare la richiesta pull con esso, e quindi non sono sicuro che i sottomoduli siano un buon modo per questo scopo. Ora vedo che probabilmente potrei diramarlo in qualche modo ... Quindi è questa la strada da percorrere?}

GitHub non supporta le richieste pull per il repository wiki , solo il repository principale (questo è un po 'un peccato, IMO, ma posso capirlo).

Ecco un modo interessante in cui un progetto gestisce gli aggiornamenti della community sul loro wiki, mantenendo comunque un controllo rigoroso, come per il codice sorgente:

Il mio flusso di lavoro proposto è questo:

1. Crea manualmente un fork del wiki di Taffy sul tuo account Github:
   • Crea un nuovo repository sul tuo account github. Chiamiamolo "Taffy-Wiki".
   • Clona il repository wiki Taffy sulla tua macchina locale da qualche parte: git clone git@github.com:atuttle/Taffy.wiki.git
   • Rimuovere il telecomando "origin" originale e aggiungere il repository github come nuovo "origin" git remote rm originegit remote add origin git@github.com:<YOUR_USERNAME>/Taffy-Wiki.git
2. Apporta le modifiche proposte localmente, quindi inseriscile nel tuo account github: git push -u origin master('-u origin master' è richiesto solo la prima volta; in seguito basta git push)
3. Invia un ticket al tracker del problema ufficiale di Taffy che mi richiede di rivedere le tue modifiche e di unirle. Assicurati di includere un link al tuo repository e descrivi cosa hai cambiato.
4. Vai a # 2

(Da Come puoi contribuire alla documentazione di Taffy .)

Se fossi in me, creerei un problema nel repository principale (cioè quello che hai biforcato) suggerendo un aggiornamento per il wiki. Se i problemi non sono abilitati, l'e-mail è l'unica opzione a cui riesco a pensare.

Ho adottato un approccio diverso a questo, che consiste nello spingere esattamente lo stesso contenuto sia nel repository principale che nel wiki. Questo non sarà per tutti i gusti, ma Risk-First è principalmente una wiki con alcune pagine Jekyll nel repository principale.

Ciò significa che il processo pull request / fork funziona correttamente. Tuttavia, dopo aver unito una richiesta pull, devo fare il passo aggiuntivo per passare al mio repository locale e quindi spingere sia al repository principale che al wiki, che git supporta bene con URL di origine multipli:

localhost:website robmoffat$ git remote show origin
* remote origin
  Fetch URL: git@github.com:risk-first/website.git
  Push  URL: git@github.com:risk-first/website.wiki.git
  Push  URL: git@github.com:risk-first/website.git
  HEAD branch: master

Per raggiungere questo obiettivo, ho unito i commit di entrambi i repository seguendo questo:

Come unire due repository Git?

E quindi spingere verso entrambi i repository in questo modo:

Git - Spingendo il codice su due telecomandi

Spero che questo aiuti qualcuno.

Finora abbiamo trovato la migliore soluzione al problema in https://devonfw.com :

1. Metti la tua documentazione nel repository git insieme al codice all'interno di una cartella della documentazione.
2. Estendi la tua build travis-ci con un po 'di magia che mette in scena tutte le modifiche da quella cartella della documentazione con le trasformazioni applicate al wiki git. Vedi l'ultimo link di esempio qui sotto.
3. Considera il wiki come vista di sola lettura sulla documentazione. Si noti che con github.com è ancora possibile visualizzare e modificare direttamente i file nella cartella della documentazione. Quindi puoi ancora correggere gli errori di battitura all'interno del browser in pochi secondi (anche come PR senza autorizzazioni sul repository) - non solo tramite il wiki.
4. Quando un collaboratore si biforca, ha anche la documentazione con il codice. Può cambiare entrambi in un PR e tutto viene rivisto nello stesso processo, quindi dopo aver unito Codice e Doc rimane sincronizzato. Hai ancora la UX migliore per leggere la documentazione nel wiki con barra laterale, ecc.

Dato che siamo OSS al 100%, amiamo condividere i nostri sforzi per giungere a questa grande soluzione. Ecco i link come esempio:

• 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

Non puoi fare una richiesta pull, ma puoi aprire un problema, incollare un link alla tua pagina wiki e lasciarli unire nella tua pagina wiki alla loro pagina wiki.

In breve:

Devono solo clonare il repository della tua pagina wiki, ( git clone YOUR_FORKED_REPO.wiki.git), comprimere tutti i tuoi commit della wiki in un unico grande commit, quindi selezionare questo grande commit schiacciato nel loro repository. Ciò porterà tutte le modifiche alla tua wiki.

Istruzioni complete:

(COPIATO DAL Gistub di Larry Botha QUI: https://gist.github.com/larrybotha/10650410 ):

---------- INIZIO DI COPIA-PASTA DALL'ALTO GISTUB GIST ------------

Unisci le modifiche del Wiki da un biforcatore Repo

Questo è ispirato (o sostanzialmente copiato) da Come unire Github Wiki cambia da un repository all'altro, da Roman Ivanov, e serve a garantire che se dovesse succedere qualcosa nell'articolo originale, le informazioni rimangono belle e sicure qui.

Terminologia

OREPO : repository originale - il repository creato o gestito dal proprietario

FREPO : il repository biforcato che presumibilmente ha aggiornamenti alla sua wiki, non ancora su OREPO

contribuire

Se desideri contribuire al wiki di un repository che hai modificato, procedi come segue:

• fork del repository
• clona solo il wiki sul tuo computer: $ g clone [FREPO].wiki.git
• apportare modifiche al repository wiki biforcuto locale
• invia le tue modifiche a GitHub

Quando sei pronto a comunicare all'autore che hai apportato modifiche, procedi come segue:

• aprire un problema su OREPO
• fornire un collegamento diretto al repository git del wiki per semplificare l'unione: ad esempio [ FREPO ] .wiki.git

Unione di modifiche

Come proprietario di OREPO , ora hai ricevuto un messaggio che ci sono aggiornamenti alla tua wiki sul FREPO di qualcun altro .

Se le modifiche al wiki sono modificate dall'ultimo wiki di OREPO , è possibile effettuare le seguenti operazioni:

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

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

$ git push origin master

Se la wiki di OREPO è in anticipo rispetto alla provenienza di FREPO , effettuare le seguenti operazioni:

$ 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

---------- FINE DELLA COPIA-PASTA DALL'ALTO GISTUB GIST ------------

Se stai bene avere un documento di una sola pagina (in realtà mi piace di più), puoi dirottare README.MDe inserire lì il contenuto del wiki.

Non solo verrà tracciato come parte del normale repository, ma verrà anche visualizzato nella home page.

Può essere fatto per iniziare con un riferimento rapido e quindi ottenere una descrizione / istruzioni più dettagliate, in modo che gli utenti normali possano colpire prima le informazioni più generiche.