![]() Note that in the above script, the secret key $GITHUB_API_KEY that’s about to be setup is used and any output generated by the command is redirected to /dev/null so that the key doesn’t show up in the build log. Git push upstream HEAD:master > /dev/null 2>&1 ![]() Git push origin HEAD:master > /dev/null 2>&1 Now clone the wiki, change the remote to point at the new repository and push. Next open the wiki of the original repository and copy the repository address, it should end with. Create a new repository and sync it with the wikiįirst start by creating a new repository, name it the same as the original repository but add -wiki to the end, the one I created is Tyriar/wiki-sync-example-wiki. In this walkthrough I’ll be using the project Tyriar/wiki-sync-example. While it takes a bit of work to setup, it’s a really nice experience for collaborators and users afterwards. The technique works by cloning the wiki, pushing it to a new repository so that pull requests can be put out against it, then creating a CI build that automates syncing between the two repositories. There is a workaround though that can allow people to submit pull requests to the wiki. Commits to documentation are mixed in with code commits.No longer highly visible users searching for documentation need to hunt through the codebase (or follow links) to find what they want.Unfortunately you cannot fork the wikis through the UI, so while you can clone the wiki and make a change to your copy, you cannot submit a pull request as your copy is not “linked” with the original repository.Ī relatively easy workaround for this issue is to just move the documentation to the project repository, this comes with a number of drawbacks however: Underneath, GitHub wikis are just Git repositories which should enable all the collaborative goodness of the projects themselves through forking and pull requests.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |