I am creating a GitHub Pages site for my project. GitHub advises generating an orphan gh-pages
branch and clearing all existing files from the branch. For my site to work, I'll need copies of the latest revisions of several JSON files from master
in the gh-pages
branch (and without them, jQuery $.getJSON()
won't work, as noted in this question).
It seems that there are (at least) two approaches to getting files from master
into gh-pages
.
1. Create gh-pages
branch from master
and then rebase gh-pages
regularly.
This approach is summarized here, and this answer discusses how to automate this process. I think the trouble with this approach is that the history of the site is now linked with the entire history of the rest of the repo, even though the history in master
isn't particularly important to the site. The gh-pages
branch might also end up with a lot of content from master
that isn't needed for the site.
2. Use git-checkout
to pull just the needed files from master
into gh-pages
regularly.
This method involves a non-traditional use of git-checkout
, described here, to copy files from one branch into another. The branch would be an orphan, as suggested by GitHub, but could still include the JSON files in master
by pulling them in with git-checkout
. My hesitation with this approach is that it means creating a commit in gh-pages
each time the files are updated from master
, which seems extraneous, since the history will then have a bunch of commits that say "Updating JSON files from master."
I'm leaning towards not worrying about the extra commits and using approach #2, but is there another approach I should consider? Are there any important advantages/disadvantages of the approaches above that I might have missed?