Git deployer plugin for Hexo.
Update Git for Windows to the latest version. (Details)
$ npm install hexo-deployer-git --save
You can configure this plugin in _config.yml
.
# You can use this:
deploy:
type: git
repo: <repository url>
branch: [branch]
token: ''
message: [message]
name: [git user]
email: [git email]
extend_dirs: [extend directory]
ignore_hidden: false # default is true
ignore_pattern: regexp # whatever file that matches the regexp will be ignored when deploying
# or this:
deploy:
type: git
message: [message]
repo: <repository url>[,branch]
extend_dirs:
- [extend directory]
- [another extend directory]
ignore_hidden:
public: false
[extend directory]: true
[another extend directory]: false
ignore_pattern:
[folder]: regexp # or you could specify the ignore_pattern under a certain directory
# Multiple repositories
deploy:
repo:
# Either syntax is supported
[repo_name]: <repository url>[,branch]
[repo_name]:
url: <repository url>
branch: [branch]
git@github.com:
) for your repository URL to avoid password prompts or access denial due to security policies.gh-pages
on GitHub.coding-pages
on Coding.net.master
.$
to read token from environment variable (recommended). Repo must be a http(s) url. More details.deploy:
repo:
# Either syntax is supported
github: https://github.com/user/project.git,branch
gitee:
url: https://gitee.com/user/project.git
branch: branch_name
repo:
takes priority.Site updated: {{ now("yyyy-MM-dd HH:mm:ss") }}
.demo
, examples
.nojekyll
in root.
public
: the public dir defaults.
# _config.yaml
deploy:
While this plugin can parse authentication token from the config, only use this method if you are sure the config will not be committed, including to a private repo. A more secure approach is to add it to the CI as an environment variable, then simply add the name of the environment variable to this plugin's config (e.g. $GITHUB_TOKEN
).
Additional guides:
The hexo-deployer-git
plugin employs a force push (git push --force
) strategy when deploying updates to your site. This approach ensures that the remote repository aligns exactly with your local deployment, providing a clean, consistent state for each update. However, it comes with an important consideration regarding custom modifications.
Using force push means that any changes made directly in the remote repository (e.g., via GitHub's web interface or through a separate git workflow) will be overwritten when the next deployment occurs. This is because force push does not merge changes; it replaces the remote content with the local version entirely.
To prevent unintended loss of work, we strongly advise adhering to the following best practices:
Centralize Changes in Your Hexo Source: Make all content and configuration changes within your local Hexo root directory. This ensures all modifications are included in the deployment process and preserved in your source control.
Avoid Direct Remote Modifications: Refrain from directly editing files in the GitHub repository through the web interface or other git methods. Doing so could lead to these changes being lost on the next deployment.
If you are using a custom domain with GitHub Pages, you might have encountered an issue where your custom domain configuration gets lost after deploying updates to your site. This problem occurs due to the overwritten / deletion of the CNAME
file in the root of the deployed directory during the git commit and push process performed by the hexo-deployer-git
plugin.
GitHub requires the CNAME
file to be present in your repository to associate your custom domain with your GitHub Pages site. When this file is missing, GitHub resets the custom domain setting, leading to the site being accessible only through the default github.io
domain.
To ensure your custom domain remains active with each deployment, you need to include the CNAME
file in your blog's source/
directory. Here's how you can do it:
CNAME
File: In the root of your blog's source/
directory, create a file named CNAME
. Inside this file, enter your custom domain name. For example, if your custom domain is example.com
, the content of the CNAME
file should be:
example.com
hexo-deployer-git
plugin to deploy your site as usual. Run hexo g -d
command, the plugin will now include the CNAME
file in the deployment, and your custom domain configuration will remain intact.hexo-deployer-git
works by generating the site in .deploy_git
and force pushing to the repo(es) in config.
If .deploy_git
does not exist, a repo will initialized (git init
).
Otherwise the curent repo (with its commit history) will be used.
Users can clone the deployed repo to .deploy_git
to keep the commit history.
git clone <gh-pages repo> .deploy_git
Remove .deploy_git
folder.
$ rm -rf .deploy_git
MIT