Once upon a time, there was a Mirror Tree.
The MirrorTree Wiki is currently organized following the diagram below.
mindmap
root((MirrorWiki))
id(server culture)
id[outlook]
id[player list]
id[activity]
id(introduction)
id[area and structs]
id[command docs]
id[feature collection]
id[regulation]
id(advances)
id[machine documentation]
id[project publicity]
id(issue report)
At present we have an alternate wiki site to be improved, which is constructed based on the MediaWiki engine.
Caution
Contributors ought to look through this section throughly before editing the website.
You may follow the steps below to deploy the website locally. Node.js is required for the deployment.
# clone the repository and install the dependencies
git clone https://github.com/MirrorTree-MC/MirrorTree.git
cd MirrorTree
npm install
# start the local server
hexo clean; hexo g -d
hexo s
.
├── source
│ ├── _posts # common posts
│ ├── docs # documentation
│ │ ├── server # culture of the server
│ │ ├── introduction # introduction for freshers
│ │ ├── advanced-info # advanced information
│ │ └── issue.md # problem solving
│ └── news # mirror news
├── .gitignore
├── _config.next.yml # configuration of NexT theme
├── _config.yml # configuration of Hexo
└── README.md # guidelines for contributors
Note
Given that Hexo has its own specific file structure as deploying a website, you may refer to the pbulic
folder in the root directory as a reference while using internal links, which is the actual root directory of the internal links.
The documentation should be clear and concise in order that problem dealing can be more efficient. You may follow the github markdown syntax when writing a document. Note that we use ###
instead of #
as the top level heading in markdown posts, and that to insert a space between Chinese and English words is strongly recommended. See Chinese Documentation Style Guide with Markdown for more information.
Tip
Trick-playing is recommended when writing a document, indicating your expressions needn't be that wikism.
A commit message should be clear and concise in order that problem dealing can be more efficient. It ought to be in the following format:
<type>(<scoop>): <subject>
// <BLANK LINE>
<body>
// <BLANK LINE>
<footer>
<type>
: The type of the commit, such asfeat
,fix
,docs
,style
,refactor
,test
,chore
, etc.<scoop>
(optional) : The scope of the commit, such asalgorithm
,communication
,archive
, etc.<subject>
: A brief summary of the commit. It should be in the imperative mood withoutdot (.)
at the end of a line.<body>
(optional) : A detailed description of the commit.<footer>
(optional) : A footer for the commit, such asBREAKING CHANGE
,ISSUES CLOSED
, etc.
Note
Although pull requests are different from commits, you may follow the same format while writing a pull request.
Copyright (c) 2024 MirrorTree
Current version is Type M Edition 0.11
2024.11.20