同步操作将从 Gitee 极速下载/Hugo-Go 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
We welcome contributions to Hugo of any kind including documentation, themes, organization, tutorials, blog posts, bug reports, issues, feature requests, feature implementations, pull requests, answering questions on the forum, helping to manage issues, etc.
The Hugo community and maintainers are very active and helpful, and the project benefits greatly from this activity. We created a step by step guide if you're unfamiliar with GitHub or contributing to open source projects in general.
Note that this repository only contains the actual source code of Hugo. For only documentation-related pull requests / issues please refer to the hugoDocs repository.
Changes to the codebase and related documentation, e.g. for a new feature, should still use a single pull request.
We have an active discussion forum where users and developers can ask questions. Please don't use the GitHub issue tracker to ask questions.
If you believe you have found a defect in Hugo or its documentation, use
the GitHub issue tracker to report
the problem to the Hugo maintainers. If you're not sure if it's a bug or not,
start by asking in the discussion forum.
When reporting the issue, please provide the version of Hugo in use (hugo version
) and your operating system.
Hugo has become a fully featured static site generator, so any new functionality must:
If it is of some complexity, the contributor is expected to maintain and support the new feature in the future (answer questions on the forum, fix any bugs etc.).
It is recommended to open up a discussion on the Hugo Forum to get feedback on your idea before you begin. If you are submitting a complex feature, create a small design proposal on the Hugo issue tracker before you start.
Note that we do not accept new features that require CGO. We have one exception to this rule which is LibSASS.
Bug fixes are, of course, always welcome.
The Hugo project welcomes all contributors and contributions regardless of skill or experience level. If you are interested in helping with the project, we will help you with your contribution.
Because we want to create the best possible product for our users and the best contribution experience for our developers, we have a set of guidelines which ensure that all contributions are acceptable. The guidelines are not intended as a filter or barrier to participation. If you are unfamiliar with the contribution process, the Hugo team will help you and teach you how to bring your contribution in accordance with the guidelines.
To make the contribution process as seamless as possible, we ask for the following:
go fmt
./docs
.git rebase -i
. It’s okay to force update your pull request with git push -f
.mage check
succeeds. Travis CI (Windows, Linux and macOS) will fail the build if mage check
fails.This blog article is a good resource for learning how to write good commit messages, the most important part being that each commit message should have a title/subject in imperative mood starting with a capital letter and no trailing period: "Return error on wrong use of the Paginator", NOT "returning some error."
Also, if your commit references one or more GitHub issues, always end your commit message body with See #1234 or Fixes #1234. Replace 1234 with the GitHub issue ID. The last example will close the issue when the commit is merged into master.
Sometimes it makes sense to prefix the commit message with the package name (or docs folder) all lowercased ending with a colon. That is fine, but the rest of the rules above apply. So it is "tpl: Add emojify template func", not "tpl: add emojify template func.", and "docs: Document emoji", not "doc: document emoji."
Please use a short and descriptive branch name, e.g. NOT "patch-1". It's very common but creates a naming conflict each time when a submission is pulled for a review.
An example:
tpl: Add custom index function
Add a custom index template function that deviates from the stdlib simply by not
returning an "index out of range" error if an array, slice or string index is
out of range. Instead, we just return nil values. This should help make the
new default function more useful for Hugo users.
Fixes #1949
Since Hugo 0.48, Hugo uses the Go Modules support built into Go 1.11 to build. The easiest is to clone Hugo in a directory outside of GOPATH
, as in the following example:
mkdir $HOME/src
cd $HOME/src
git clone https://github.com/gohugoio/hugo.git
cd hugo
go install
Note: Some Go tools may not be fully updated to support Go Modules yet. One example would be LiteIDE. Follow this workaround for how to continue to work with Hugo below
GOPATH
.
For some convenient build and test targets, you also will want to install Mage:
go get github.com/magefile/mage
Now, to make a change to Hugo's source:
Create a new branch for your changes (the branch name is arbitrary):
git checkout -b iss1234
After making your changes, commit them to your new branch:
git commit -a -v
Fork Hugo in GitHub.
Add your fork as a new remote (the remote name, "fork" in this example, is arbitrary):
git remote add fork git@github.com:USERNAME/hugo.git
Push the changes to your new remote:
git push --set-upstream fork iss1234
You're now ready to submit a PR based upon the new branch in your forked repository.
Hugo uses mage to sync vendor dependencies, build Hugo, run the test suite and other things. You must run mage from the Hugo directory.
cd $HOME/go/src/github.com/gohugoio/hugo
To build Hugo:
mage hugo
To install hugo in $HOME/go/bin
:
mage install
To run the tests:
mage hugoRace
mage -v check
To list all available commands along with descriptions:
mage -l
Note: From Hugo 0.43 we have added a build tag, extended
that adds SCSS support. This needs a C compiler installed to build. You can enable this when building by:
HUGO_BUILD_TAGS=extended mage install
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。