Vi uma página wiki no GitHub que não está aberta para edição. Então bifurquei o projeto, editei-o no "final" e tentei fazer uma solicitação de recebimento. Acontece que o wiki não está no projeto e não há uma maneira de confirmar as alterações.

Além de enviar por e-mail, existe uma maneira de prosseguir se eu quiser sugerir uma alteração no wiki nesse caso?

^{Nesse ponto, descobri o que parece ser uma alternativa em "Perguntas com títulos semelhantes", mas ainda não consegui fazer a solicitação de recebimento e, portanto, não tenho certeza de que os submódulos sejam uma boa maneira para esse fim. Agora vejo que provavelmente poderia ramificá-lo de alguma forma ... Então é este o caminho a percorrer?}

O GitHub não suporta solicitações pull para o repositório wiki , apenas o repositório principal (isso é uma pena, IMO, mas eu posso entender).

Aqui está uma maneira interessante de um projeto gerenciar atualizações da comunidade em seu wiki, mantendo um controle rígido, como no código-fonte:

Meu fluxo de trabalho proposto é o seguinte:

1. Crie manualmente um fork do wiki do Taffy na sua conta do Github:
   • Crie um novo repositório na sua conta do github. Vamos chamá-lo de "Taffy-Wiki".
   • Clone o repositório wiki do Taffy em sua máquina local em algum lugar: git clone git@github.com:atuttle/Taffy.wiki.git
   • Remova o controle remoto "origem" original e adicione seu repositório no github como nova "origem" git remote rm originegit remote add origin git@github.com:<YOUR_USERNAME>/Taffy-Wiki.git
2. Faça as alterações propostas localmente e envie-as para a sua conta do github: git push -u origin master('-u origin master' só é necessário na primeira vez; depois é só fazer git push)
3. Envie um ticket para o rastreador oficial de problemas do Taffy, solicitando que eu revise suas alterações e integre-as. Lembre-se de incluir um link para seu repo e descrever o que você mudou.
4. Goto # 2

(De Como você pode contribuir com a documentação do Taffy .)

Se fosse eu, eu criaria um problema no repositório principal (ou seja, o que você bifurcou) sugerindo uma atualização para o wiki. Se os problemas não estiverem ativados, o e-mail será sobre a única outra opção em que posso pensar.

Eu adotei uma abordagem diferente para isso, que é inserir exatamente o mesmo conteúdo no repositório principal e no wiki. Isso não será do gosto de todos, mas o Risk-First é principalmente um wiki com algumas páginas Jekyll no repositório principal.

Isso significa que o processo pull request / fork funciona bem. No entanto, depois de mesclar uma solicitação de recebimento, eu tenho que fazer a etapa extra de acessar o repositório local e depois passar para o repositório principal e o wiki, que o git suporta bem com URLs de origem múltipla:

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

Para conseguir isso, mesclamos os commits de ambos os repositórios, após o seguinte:

Como você mescla dois repositórios Git?

E, em seguida, pressione os dois repositórios como este:

Git - Enviando código para dois controles remotos

Espero que isso ajude alguém.

Encontramos a melhor solução para o problema até agora em https://devonfw.com :

1. Coloque sua documentação no repositório git junto com o código dentro de uma pasta de documentação.
2. Estenda sua construção travis-ci com alguma mágica que encena todas as alterações dessa pasta de documentação com as transformações aplicadas ao wiki git. Veja o último exemplo de link abaixo.
3. Considere o wiki como exibição somente leitura na documentação. Observe que, com o github.com, você ainda pode visualizar e editar diretamente os arquivos na pasta de documentação. Assim, você ainda pode corrigir erros de digitação no navegador em segundos (mesmo que o PR sem permissões no repositório) - mas não através do wiki.
4. Quando um colaborador bifurca, ele também possui a documentação com o código. Ele pode alterar ambos em um PR e tudo é revisado no mesmo processo, portanto, após a mesclagem de Code e Doc, permanece sincronizado. Ainda assim, você tem o UX mais agradável para ler a documentação no wiki com barra lateral, etc.

Como somos 100% OSS, gostamos de compartilhar nossos esforços para chegar a essa ótima solução. Aqui estão os links como exemplo:

• 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

Você não pode fazer uma solicitação de recebimento, mas pode abrir um problema, colar um link para a sua página da wiki e deixá-los mesclar na sua página da wiki à sua página da wiki.

Em resumo:

Eles só precisam clonar seu repositório de páginas da wiki, ( git clone YOUR_FORKED_REPO.wiki.git), compactar todos os commits do wiki em um grande commit e, em seguida, escolher esse commit squash em seu repositório. Isso trará todas as alterações no seu wiki.

Instruções completas:

(COPIADO DA essência do github de Larry Botha AQUI: https://gist.github.com/larrybotha/10650410 ):

---------- Início da pasta de cópias da lista anterior do Github ------------

Mesclar alterações da wiki de um repositório do Github bifurcado

Isso é inspirado (ou basicamente copiado) de Como mesclar alterações da wiki do Github de um repositório para outro , de Roman Ivanov, e serve para garantir que algo aconteça no artigo original, as informações permanecem agradáveis ​​e seguras aqui.

Terminologia

OREPO : repo original - o repo criado ou mantido pelo proprietário

FREPO : o repositório bifurcado que provavelmente possui atualizações para seu wiki, ainda não no OREPO

Contribuindo

Se você deseja contribuir para o wiki de um repositório que você bifurcou, faça o seguinte:

• bifurcar o repo
• clone apenas o wiki em sua máquina: $ g clone [FREPO].wiki.git
• faça alterações no seu repositório wiki bifurcado local
• envie suas alterações para o GitHub

Quando estiver pronto para informar ao autor que você tem alterações, faça o seguinte:

• abrir um problema no OREPO
• forneça um link direto para o repositório git do seu wiki para facilitar a fusão: por exemplo, [ FREPO ] .wiki.git

Mesclando alterações

Como proprietário do OREPO , você recebeu uma mensagem de que há atualizações no seu wiki no FREPO de outra pessoa .

Se as alterações do wiki forem bifurcadas do wiki mais recente do OREPO , faça o seguinte:

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

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

$ git push origin master

Se o wiki do OREPO estiver à frente de onde o FREPO bifurcou, faça o seguinte:

$ 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

---------- FIM DE CÓPIA DE PASTA DA GISTÃO ACIMA DO GITHUB ------------

Se você tem permissão para ter um documento com uma única página (eu realmente gosto mais), você pode seqüestrar README.MDe colocar o conteúdo do wiki lá.

Além de ser rastreado como parte do repositório normal, ele também será exibido na página inicial.

Isso pode ser feito para começar com uma referência rápida e, em seguida, entrar em descrição / instruções mais detalhadas, para que os usuários comuns acessem primeiro as informações mais genéricas.