在 Github 页面上将子目录设置为网站根目录

小开

最佳答案

There is a detailed gist with all the required steps.

The gist is here:
https://gist.github.com/cobyism/4730490

From the gist

Deploying a subfolder to GitHub Pages

Sometimes you want to have a subdirectory on the master branch be the root directory of a repository’s gh-pages branch. This is useful for things like sites developed with Yeoman, or if you have a Jekyll site contained in the master branch alongside the rest of your code.

For the sake of this example, let’s pretend the subfolder containing your site is named dist.

Step 1

Remove the dist directory from the project’s .gitignore file (it’s ignored by default by Yeoman).

Step 2

Make sure git knows about your subtree (the subfolder with your site).
git add dist && git commit -m "Initial dist subtree commit"
Step 3

Use subtree push to send it to the gh-pages branch on GitHub.
git subtree push --prefix dist origin gh-pages
Boom. If your folder isn’t called dist, then you’ll need to change that in each of the commands above.

If you do this on a regular basis, you could also create a script containing the following somewhere in your path:

#!/bin/sh
if [ -z "$1" ]
then
echo "Which folder do you want to deploy to GitHub Pages?"
exit 1
fi
git subtree push --prefix $1 origin gh-pages

Which lets you type commands like:
git gh-deploy path/to/your/site

小开

Since August 2016 you can use /docs subfolder of the master branch for your sources.

So if you can tell to your site generator to use /docs in place of /build you are done (without subtree).

Note: As pointed out by @thislooksfun in the comment, this is valid only for project pages (like <username>.github.io/<projectname>), but not for user or organization pages (like <name>.github.io).

小开

push-dir will do it:

npm install push-direxample
push-dir --dir=build --branch=gh-pages

小开

Somehow for me, the accepted answer only runs the first time. Re-doing it throws errors.

I solved it by running the commands below:

git checkout --orphan gh-pages
git --work-tree build add --all
git --work-tree build commit -m 'gh-pages'
git push origin HEAD:gh-pages --force
git checkout -f master

小开

To get this to work for gh-pages branch for hugo sites that use a public/ folder, here is what I have working that is super hacky but gets the job done:

Note: hugolanding is the folder root where your config.toml is, this script runs from a scripts folder, you could totally move it elsewhere and change that line.

#!/bin/bash
# move to root
cd ../hugolanding
# generate public content
hugo -D
# prep copy folder
rm -rf /tmp/public && mkdir -p /tmp/public
# copy out of git shit
cp -R public/* /tmp/public
# git yolo everything
git add -A
git commit -m 'updates to public'
git push --recurse-submodules=on-demand
git checkout gh-pages
cd ..
cp -R /tmp/public/* .
git add -A
git commit -m 'updated gh-pages'
git push --recurse-submodules=on-demand
echo "done"
git checkout main

小开

I think git-worktree, and deployment from a seperate branch, is a cleaner alternative, since I won't have commits in my main branch, intermingled with commits from re-deployment, which I find more succinct, and I won't have to delete the remote branch every time, if I use git subtree, which is unnecessary.

git-worktree mounts your sub-directory, dist, in this example, to a separate branch, gh-pages.

Here's how:

git branch --track gh-pages origin/gh-pages # Create new gh-pages branch; Add tracking
git checkout --orphan gh-pages              # Initialize gh-pages without main's history
git reset --hard                            # Remove all history
git commit --allow-empty -m "Init"          # First commit without any files
git checkout main                           # Go back to main (or master) branch
git worktree add dist gh-pages              # Mount dist and bind it to the gh-pages branch

dist is an npm build script which looks like:

"scripts": {
...
"dist": "ng build --configuration production && echo 'gitdir: /home/<user>/<repo>/.git/worktrees/dist' > ./dist/.git"
...
}

All it does is re-creates the git-worktree reference, because the .git file in dist was removed by ng build by default. This reference is needed by git to link dist to the index.

And the workflow goes something like this:

npm run dist            # Build website with new changes; Removes dist and re-creates it
cd dist                 # Move to gh-pages branch by switching into a directory (cool huh)
git add .               # Add all generated files to staging area
git commit -m "v0.0.3"  # Update the version history of the gh-pages branch
git push                # Push changes to gh-branch

If you run git status it will reply On branch gh-pages.
And git log will show one commit "Init".

But when you cd .. and run git status again, the response will be On branch main.
And git log will show all of your original commits to main.

So what's happened here is quite interesting. The folder dist now has a separate branch, with it's own, unrelated history to main, and all you have to do to switch is cd dist to access that branch (gh-pages).

This is unlike git checkout dist, which would append the dist directory, with the auto generated build files to your working tree, intermingling your main and deployment histories, which is inconvenient.

Here your src files will be untouched, along with their own history in main, or cd .., and only the files needed for deployment, will be on this branch, which is really convenient, because it keeps the src history seperate from the deployment history.

Now you'd deploy not from a folder, but from a branch, which holds the latest compiled version of your site in GitHub pages, and is built from /(root).

index.html is under build/, so I want to make that the default www path.

Here make certain that the repo that you've created is <username>.github.io. I made this same mistake, by having a different repo name, and was frustrated.

So when users hit username.github.io it renders the content within that subdirectory and yet it doesn't show "/build/" on the URL, cause that's set as the root folder.

Of course there's probably an improvement that could be done here as well. For example make npm run dist do all of this, but my personal preference is to do these steps manually.