3 ms·

My stumbling block with ghpages is the workflow. I have not found a good way to work with the project in the master branch and then my docs/web-content in the g

by dfc 15y ago

My stumbling block with ghpages is the workflow. I have not found a good way to work with the project in the master branch and then my docs/web-content in the ghpages branch. A lot of time all I really need to do is take something from my master/working branch and transmogrify it and dump the output to ghpages. Maybe its something about my git-fu? Or maybe most people's ghpages is less dependent/tied-to what is in their master branch. Am I missing something obvious?

dfc 15y ago
Does anyone know what would happen if inside my main repo I had a submodule that was just a checkout of my ghpages branch? ./project <- Main repo ./project/project-ghpages <- same repo but gh-pages branch
- barrybe 15y ago
  That's how I do it, it works great that way. I didn't actually set up the gh-pages as a proper submodule, I just cloned the branch to a folder. Then I added the gh-pages folder to the top level .gitignore.
  - dfc 15y ago
    That's probably better than my ill-conceived submodule idea.
orta 15y ago
In a project I have where I generated pages based of code in my master I would have two folders that both were the same repo, one just stayed as master and the other as gh-pages. Meaning I could automate moving things and then pushing from that directory.
mdehaan 15y ago
I find the gh_pages branch confusing too -- the idea that a branch doesn't contain something related to the other branches feels weird. What I've found is it's easier to create a free organization, and that way you can get a organization.github.com project created and host the pages there.... this is easier than juggling the spare branch. Obviously smaller starter projects should not do this, but you could use username.github.com/yourproject name and not keep the documentation on the branch just as easily. Presto, no gh_pages branch, but all of the advantages of hosting web content.
ajross 15y ago
You can create a local git containing only the gh-pages branch: mkdir my-project-pages cd my-project-pages git init git remote add origin git@github.com:myusername/myproject.git git pull origin gh-pages Now just treat them as distinct "repos" and push independently. The basic idea here is that you're breaking up "clone" (which by default pulls everything) into its composite steps.

by dfc 15y ago

dfc 15y ago

Does anyone know what would happen if inside my main repo I had a submodule that was just a checkout of my ghpages branch? ./project <- Main repo ./project/project-ghpages <- same repo but gh-pages branch

barrybe 15y ago
That's how I do it, it works great that way. I didn't actually set up the gh-pages as a proper submodule, I just cloned the branch to a folder. Then I added the gh-pages folder to the top level .gitignore.
- dfc 15y ago
  That's probably better than my ill-conceived submodule idea.

orta 15y ago

In a project I have where I generated pages based of code in my master I would have two folders that both were the same repo, one just stayed as master and the other as gh-pages. Meaning I could automate moving things and then pushing from that directory.

mdehaan 15y ago

I find the gh_pages branch confusing too -- the idea that a branch doesn't contain something related to the other branches feels weird. What I've found is it's easier to create a free organization, and that way you can get a organization.github.com project created and host the pages there.... this is easier than juggling the spare branch. Obviously smaller starter projects should not do this, but you could use username.github.com/yourproject name and not keep the documentation on the branch just as easily. Presto, no gh_pages branch, but all of the advantages of hosting web content.

ajross 15y ago

You can create a local git containing only the gh-pages branch: mkdir my-project-pages cd my-project-pages git init git remote add origin git@github.com:myusername/myproject.git git pull origin gh-pages Now just treat them as distinct "repos" and push independently. The basic idea here is that you're breaking up "clone" (which by default pulls everything) into its composite steps.