How can I make a pull request for a wiki page on GitHub?

Question

I saw a wiki page on GitHub that isn't open for editing. Then I forked the project, edited it on "my end" and tried to do a pull request. It turns out, the wiki isn't in the project, and there isn't a way to commit changes to it.

Other than e-mailing, is there a way to proceed if I want to suggest a change on the wiki in this case?

^{At this point I found out what seems like an alternative under "Questions with similar titles", but I couldn't do the pull request with it yet, and so I'm not sure submodules is a good way for this purpose. I now see I could probably branch it somehow... So is this the way to go?}

Academe

Reported on github.com/isaacs/github/issues/846 – Ajani

I know I'm late to the party 🎉 on this one, but I think using the .wiki git repo as a submodule of the main project repo seems like the best approach to this situation. – Fuel

Workaround to enable pull requests on GitHub wikis: growingwiththeweb.com/2016/07/… – Kling

More recently reported on github.com/orgs/community/discussions/50163 – Hallee

Related: On GitHub, can I fork just a wiki? – Freeliving

Please vote for github.com/orgs/community/discussions/50163 – Impermanent

Answer 1

GitHub now supports this and you can find details at Adding or editing wiki pages.

It's treated as a "normal" repository now, with branches, pull requests, commits, etc.

Manhunt

looking back at this question, i knew even back then that it didn't belong to stackoverflow because of the github specificity... but today i have a small regret for even insisting so much on using github! we need git solutions like sourcehut that promote open source while opening their source as well! even more so if they use agpl3+. in any case... thanks for the update. i don't know why i couldn't accept this as the answer now. – Academe

This is incorrect. Github does not support PR's for the wiki repo's directly. You'd have to follow @Calrion's answer above which would force you to replace the remote with your main repository's remote address and push your branches to it. At that point you can create PR's, which in turn would update your wiki. – Stephine

GitHub still doesn't support handling branches for the Wiki repository at GitHub. I.e. there is no Pull Request available. – Unthinkable

Answer 2

GitHub doesn't support pull requests for the wiki repository, only the main repository (this is a bit of a shame, IMO, but I can understand it).

Here's an interesting way one project manages community updates to their wiki, while still keeping tight control, as for source code:

My proposed workflow is this:

1. Manually create a fork of the Taffy wiki on your Github account:
   • Create a new repository on your github account. Let's call it "Taffy-Wiki".
   • Clone the Taffy wiki repo to your local machine somewhere: git clone [email protected]:atuttle/Taffy.wiki.git
   • Remove the original "origin" remote and add your github repo as new "origin" git remote rm origin and git remote add origin [email protected]:<YOUR_USERNAME>/Taffy-Wiki.git
2. Make your proposed changes locally, then push them to your github account: git push -u origin master ('-u origin master' only required the first time; afterwards just do git push)
3. Submit a ticket to the official Taffy issue tracker requesting me to review your changes and merge them in. Please be sure to include a link to your repo and describe what you've changed.
4. Goto #2

(From How you can contribute to Taffy documentation.)

If it were me, I'd create an issue in the main repository (that is, the one you forked) suggesting an update to the wiki. If issues aren't enabled, then email's about the only other option I can think of.

Singlebreasted

@Chi-YoungJeffreyLii Those commands aren't mine but come from the blog post I quoted (I linked the source below the quote). They're command-line Git commands, which should work on any platform with Git, including Windows, and including a UNIX or GNU/Linux OS with the Bash shell. – Singlebreasted

Nitpick: The origin remote remove/add sequence is perhaps a tad (unnecessarily) convoluted, plus the "fork" is technically not the origin so the name is misleading. I suggesting only adding a second remote on the local clone for the new personal GitHub repository (e.g. named "personal") and push to it normally. That way one can also still fetch from the real origin repository normally to synchronize with the work of others. – Amish

This is all too much for me. I just clone the wiki, commit my changes locally, create a patch off that commit, and submit the patch in a Discussion or Issue. – Coachandfour

Please vote for github.com/orgs/community/discussions/50163 – Impermanent

Answer 3

Unfortunately github does not offer PRs for Wikis. However, we have found the best solution for the problem so far in our github project (see e.g. https://github.com/devonfw/devon4j):

1. Put your documentation into the Git repository together with the code inside a documentation folder.
2. Add a Github Action workflow with some magic that stages all changes from that documentation folder with transformations applied to the wiki Git. See example link 8 below.
3. Consider the wiki as read-only view on the documentation. Please note that with github.com you can still view and directly edit the files in the documentation folder. So you still can fix typos within the browser within seconds (even as PR without permissions on the repo) - just not via the wiki.
4. When a contributor forks, he/she also has the documentation with the code. He/she can change both in one PR and all gets reviewed in the same process, so after merge, code and documentation remains in sync. Still you have the nicer UX for reading documentation in the wiki with sidebar, etc.

As we are 100% OSS, we love to share our hard efforts to come to this great solution. Here are the links as example:

• https://devonfw.com/website/pages/docs/master-devon4j.asciidoc_introduction.html
• Architecture
• devon4j, Architecture
• devonfw for Java 3.2.0 (2019)
• devon4j/.github/workflows/github_actions.yml

Acacia

This is probably good advice for how GitHub projects should manage their wikis, but it doesn't really answer the question about what a contributor should do for projects that don't follow this pattern. – Driskell

The first link is broken (404). – Intravenous

We have meanwhile switched from Travis-CI to github actions: github.com/devonfw/devon4j/blob/develop/.github/workflows/… Also I can recommend to use antora.org for more advanced sites. Indeed this is more the hint for the maintainers side. The original question was answered by @Singlebreasted – Restraint

This answer is a joke. You're not answering the question at all and are here simply to shamelessly promote your company. This should be deleted... – Yahwistic

The simple answer is "github does not support PRs for wikis". This is not very helpful as people looking here want a workaround for the problem. There may be 2 PoVs: developers providing a github project and contributors wanting to create such PR. For the first group I wrote my answer since I had the same problem and it took my team months to find an acceptable and working solution. The workflow we have created has also been adopted as other answer to this question. Also the upvotes for my answer are IMHO showing that it has been helpful for some people. What company do I promote? – Restraint

Answer 4

I've taken a different approach to this, which is to push exactly the same content into both the main repo and the wiki. This won't be to everyone's taste, but Risk-First is mainly a wiki with a few Jekyll pages in the main repository.

This means the pull request/fork process works fine. However, after merging a pull-request, I have to do the extra step of pulling to my local repository and then pushing to both the main repository and the wiki, which Git supports fine with multiple origin URLS:

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

In order to achieve this, I merged the commits from both repositories following this:

How do you merge two Git repositories?

And then push to both repositories like this:

Git - Pushing code to two remotes

Recrudescence

FYI, I stand by this approach - it worked out pretty well. However, for completely different reasons I ended up migrating the whole lot into Jekyll so this isn't how riskfirst works anymore – Recrudescence

Answer 5

You can't do a pull request, but you can open an issue, paste a link to your wiki page, and let them merge in your wiki page to their wiki page.

Wikis on GitHub are full independent git repositories, so you can treat them as such. Therefore, the following works.

In short:

They just need to clone your wiki page repository, (git clone YOUR_FORKED_REPO.wiki.git), squash all of your wiki commits into one big commit, then cherry-pick this big squashed commit onto their repository. That will bring in all of your wiki changes into their wiki.

Full instructions:

(Copied from Larry Botha's GitHub gist here: Merge wiki changes from a forked GitHub repository):

Merge Wiki Changes From A Forked GitHub Repo

This is inspired (or basically copied) from How To Merge GitHub Wiki Changes From One Repository To Another, by Roman Ivanov, and serves to ensure that should something happen to the original article, the information remains nice and safe here.

Terminology

OREPO: original repo - the repo created or maintained by the owner

FREPO: the forked repo that presumably has updates to its wiki, not yet on the OREPO

Contributing

Should you want to contribute to the wiki of a repo you have forked, do the following:

• fork the repo
• clone only the wiki to your machine: $ g clone [FREPO].wiki.git
• make changes to your local forked wiki repo
• push your changes to GitHub

Once you are ready to let the author know you have changes, do the following:

• open an issue on OREPO
• provide a direct link to your wiki's git repo for ease of merging: i.e. [FREPO].wiki.git

Merging Changes

As the owner of OREPO, you have now received a message that there are updates to your wiki on someone else's FREPO.

If wiki changes are forked from latest OREPO wiki, you may do the following:

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

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

$ git push origin master

If OREPO wiki is ahead of where FREPO forked from, do the following:

$ 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 - [description]"
$ git checkout master

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

See also

1. A very beginner-friendly answer I just wrote: On GitHub, can I fork just a wiki?

Freeliving

Unfortunately the above approach doesn't work as the Wiki in the forked repo remains empty. – Achromatous

@monochromec, the wiki is a repo. It is an independent, standalone, git repo. So, clone the original wiki repo, then set an upstream pointing to the new wiki repo, and push to it to get all of the wiki copied to the new repo's wiki repo too. – Freeliving

@monochromec, if the code repo you are talking about is public, send me the link, and I'll clone it and do it to show you the exact steps. When I say "wiki repo", I do not mean "repo that has a wiki", I mean "repo that is a wiki, that is associated with some other code repo." Every git repo consists of two completely separate git repos: 1) the code repo, and 2) the wiki repo. It's just that most people (98%?) have never learned that the wiki is a separate git repo. – Freeliving

Send me the link; I'll give you the steps. – Freeliving

IC, hence the misunderstanding. I actually meant a GH repo that has an associated wiki as part of the repo. Thanks for the clarification!! – Achromatous

@monochromec, I think we are still having a misunderstanding. Let me give you an example: here's a repo: github.com/microsoft/TypeScript. Its HTTPS URL is https://github.com/microsoft/TypeScript.git. If you click "Wiki" at the top of it, you'll end up here: github.com/microsoft/TypeScript/wiki. This wiki is a separate git repo. It's HTTPS URL is https://github.com/microsoft/TypeScript.wiki.git. That's a separate git repo. Here's my fork of the Typescript repo: github.com/ElectricRCAircraftGuy/TypeScript. – Freeliving

My Wiki (github.com/ElectricRCAircraftGuy/TypeScript/wiki) is empty. But, I can clone and push the other git wiki repo to my git wiki repo if I want to copy the wiki too. Once I've forked the TypeScript repo, there are now 4 repos: the typescript repo, its wiki repo, my forked typescript repo, and my empty wiki repo. – Freeliving

Back to your original comment: Unfortunately the above approach doesn't work as the Wiki in the forked repo remains empty. If your goal is to copy the wiki repo into your fork so your fork has the same wiki, ask. I'll show you. I'm unsure what you are trying to do. But keep in mind, those 2 GitHub repos are made up of 4 git repos. Each wiki attached to a GitHub repo is a separate git repo. Git and GitHub are not the same thing. One GitHub repo is made up of 2 Git repos, one for the repo and one for the attached wiki. – Freeliving

See also: On GitHub, can I fork just a wiki?. It has the steps. It could be clearer, but the commands are all there. – Freeliving

Thanks for the clarification. The wiki that I try to clone is the glances one: github.com/nicolargo/glances . When I clone the project repo, the wiki in the clone remains empty. github.com/nicolargo/glances.wiki.git results in a 404 error page, so does github.com/monochromec/glances.wiki.git . Maybe I am barking up the completely wrong tree... – Achromatous

@monochromec, I wrote a beginner-friendly answer: On GitHub, can I fork just a wiki? – Freeliving

Excellent - that answers my question. Thanks a LOT for your step-by-step explanation! – Achromatous

@monochromec, you're welcome. If it's useful, be sure to upvote it to make it stick out to help others. People generally only look at the most upvoted 1 or 2 answers. – Freeliving

I think I already did. If not, please let me know what else can be done. And thanks again for your efforts - this is the spirit that really makes open source fly... – Achromatous

@monochromec, my answer has 0 upvotes. To upvote, see an image of where to click here. – Freeliving

Answer 6

If you are ok to have a single page long document (I actually like it more), you can hijack the README.MD and put the content of the wiki there.

Not only it will be tracked as part of the normal repository, it will also be displayed on the home page.

It can be made to start with a quick reference and then get into more detailed description/instructions, so that the regular users will hit first the more generic information.

Clownery

Thats good only for documentation that another tech user will read. If its for generic public, they don't want to scroll miles and miles of text. – Compiler

Answer 7

In addition to the @Gabriel Staples answer, you could also create a git patch file and attach it when you create an issue on the upstream repo. That way they can easily apply it...

Geddes

Answer 8

All the other answers here either describe manual processes or involve Travis CI, so here's one with Github workflows.

Assuming you already have a wiki:

1. Clone the wiki locally
2. Copy all the files from the wiki repository to a "wiki" directory in your main repository
3. Add a Github workflow file according to the README in https://github.com/Andrew-Chen-Wang/github-wiki-action

Now every push to the master/main branch results in the Wiki being updated and others can create PRs to update the wiki files in the main repository.

Alcuin