You really don’t need this complex approach.
Simply add your own repo as a submodule (of itself!), submodule following the gh-pages
branch (since a submodule can follow the latest commit of a branch)!
git checkout master
git rm -r gh-pages # save your data first
git submodule add -b gh-pages -- /remote/url/of/your/own/repo
git commit -m "ADd gh-pages branch as submodule"
git push
That way, you can change files either in your main branch, or in the gh-pages
folder (which is actually a submodule)
Whenever you are making changes in gh-pages
folder, don’t forget to commit there, and in the main folder of your repo in order to record the new gitlink (special entry in the index) reprsenting the new SHA1 of the gh-pages
submodule.
cd myrepo/gh-pages
# modify files
git add .
git commit -m "modify gh-pages files"
cd .. # back to myrepo folder
git add gh-pages
git commit -m "record gh-pages new SHA1"
git push
With git 2.7+, you can set:
cd /path/to/main/repo
git config push.recurseSubmodules on-demand
Then a single git push
from your main repo will also push the gh-pages
submodule to the gh-pages
branch.
Later, a single git clone
would clone both your main repo and its gh-pages
branch (in the gh-pages
submodule folder).
That way, you always have both content visible.
And you don’t need a complex “synchronization/copy” mechanism.
Update August 2016: Simpler GitHub Pages publishing now allows to keep your page files in a subfolder of the same branch (no more gh-pages
needed):
You don’t need the submodule approach anymore, since your pagers can be in a subfolder within the same branch.