Accessing some files from master in gh-pages branch

Question

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?

Answer 1

Github pages processing

1. Once pulled to your publishing branch ( gh-pages for project repository or master for a user repository (eg : username.github.io)) your site is generated using Jekyll processing.

2. An other option is to instruct github pages not to use jekyll processing but just copy files from publishing branch. This is done by creating a .nojekyll file at the root of you repository.

Suggested process

In your case the idea can be to version both python scripts and web site files in gh-pages branch.

|-- _python_scripts
|   |-- script.py
|   |-- ...
|-- index.html
|-- script.js
|-- dogs.json

Using the first processing mechanism (with jekyll) this will result in _python_script folder being ignored for publication, and all other files being published.

Conclusion

You have a clear process with a commit history for datas gathering, processing and presentation. This the project history and from my point of view datas history is as important as presentation history, maybe more.

My two cents.