Consider removing gh-pages branch and instead recommending using the master branch even for project pages

[daattali]

GitHub now allows the website to be built directly from the master branch, not only from gh-pages. For projects that are primarily a software project, and the code in their git repo is code for their software, it still makes sense to use gh-pages as their website branch. But since beautifuljekyll it meant to be a website, I think it makes sense for this repository to be served directly from master by default because it's not common that a beautifuljekyll fork needs separate master and gh-pages branch.

If anyone has good reasons against this, please let me know.

[VincentTam]

I think it makes sense for this repository to be served directly from master by default because it's not common that a beautifuljekyll fork needs separate master and gh-pages branch.

There's a situation that one separate these two branches. In case of developping and contributing back to this theme, one might want to test the new features by merging them against the fork's gh-pages branch. The master branch exists when one clicks the "Fork" button, and it serves as a base point for new branches.

However, there're usually much more users than developers, so perhaps the following line needs to be updated.

https://github.com/daattali/beautiful-jekyll/blob/94161dbef714a6ca0be122b46df3ea2b4e6c4064/staticman.yml#L28

[daattali]

There are certainly cases where gh-pages makes sense, such as when this theme is used as the website of a code project (in which case master would host the actual project codebase and gh-pages would host beautifuljekyll).

But I think for the vast majority of users, master makes sense and gh-pages isn't necessary. And I think that for the few cases where gh-pages makes sense, it's for people who are advanced enough that they would know how to do that anyway. Would you agree?

[VincentTam]

But I think for the vast majority of users, master makes sense and gh-pages isn't necessary. And I think that for the few cases where gh-pages makes sense, it's for people who are advanced enough that they would know how to do that anyway. Would you agree?

Yeah, of course. Thinking about some recent repos for Beautiful Jekyll sites using names other than *.github.io, I had omitted project page users capabilities. So let's forget about my proposal.

[abelcheung]

It looks like to me that, how users are integrating this theme into their workflow is a non-issue, under the context of this report. Be it a fork, file copy or whatever, people always do one thing in common: use the master branch of this theme as a basis. The gh-pages branch of this theme only serves as a distraction as it's unmaintained.

[daattali]

@abelcheung those are exactly my thoughts. But I don't want to actually remove the gh-pages branch because it's used to create the demo site, which I do think is useful to have. Do you have an idea what to do about that?

Another question I'm not sure about is whether it's even possible to set up the repository so that by default when someone forks it into a project page, it will be configured to serve from master instead of from gh-pages. It seems to me that gh-pages is the default and I can't change that for forks

[abelcheung]

don't want to actually remove the gh-pages branch because it's used to create the demo site

This one is very easy. Under Setting → Github Page section, pick master branch instead of gh-pages branch, and it's done.

whether it's even possible to set up the repository so that by default when someone forks it into a project page, it will be configured to serve from master

If you want it to be forked, serving as project doc / demonstration website, I can see 2 ways possible to make it happen:

Create new repo specific for project doc purpose

In this case, create a separate repo for website purpose only, named like myproject-doc. Then the final URL would look like https://username.github.io/myproject-doc

Create new organization user

Name this organization as your project name, as long as others didn't register same name beforehand. Because each account allows one unsuffixed website, so the theme can be forked, and repo renamed as myproject.github.io. For those managing multiple projects, create one account per project and repeat same process. (disclaimer: I haven't really tested myself)

[daattali]

I mean that https://deanattali.com/beautiful-jekyll/ is being served from gh-pages, and I can't serve that from master because master is where the general template is at. The website that i'm serving is a bit different (it has this section for example that I don't want to include in the forked repos)

The problem for my second question is that http://deanattali.com/beautiful-jekyll is already being linked from many places so I can't create a different project/organization for the demo website. It needs to live in that URL

[VincentTam]

That's your personal domain, not GitHub's one: *.github.io. Recall that to test the PR for the Staticman integration, you've created https://daattalitest.github.io, so you've actually done almost both of @abelcheung's suggestions.

• Create new organization user: @daattalitest
• Create new repo specific for project doc purpose: https://github.com/daattalitest/daattalitest.github.io

[daattali]

Thanks for your input Vincent.

That is my github.io - deanattali.com is the domain name attached to daattali.github.io (https://github.com/daattali/daattali.github.io/blob/master/CNAME)

Creating a new website is not a problem. The problem is that the current one has many links all over the internet, so I do need the previous URL to work.

[VincentTam]

I'm not familiar with CNAME, since a GitHub/GitLab domain would satisfy many amateurs like me. I'm just wondering the possibility of setting a redirection

https://deanattali.com/beautiful-jekyll/ → https://daattalitest.github.io/

instead of

https://deanattali.com/beautiful-jekyll/ → https://daattali.github.io/beautiful-jekyll/

(Edit: corrected links)

But it seems that this idea doesn't work due to the CNAME problem that you've just raised. I've read this Stack Overflow answer, which explains some basics that you might know already.

---

Edited: I wonder if setting the baseurl and url in the Jekyll config file from your 2nd account would work. Only a few users know that. In this way, you may safety delete the gh-pages branch of this GitHub repo.

https://github.com/daattali/beautiful-jekyll/blob/94161dbef714a6ca0be122b46df3ea2b4e6c4064/_config.yml#L13-L17

[abelcheung]

This is an odd twist. With so many things set in stone, my take is, bit the bullet and have gh-pages well maintained. But I don't mean maintaining gh-pages as a separated burden. Bundle all custom changes (config, index.html additions etc) together as a single patch, then git rebase this changeset on top of most current master, whenever enough changes in master branch are accumulated.

[daattali]

@VincentTam setting baseurl/url on the second account won't work. The domain name that I bought cannot point to two different github users.

@abelcheung yeah I may just do that. Although that still leaves one problem: I would love for new users who fork this repository to only have master serve as their website , not gh-pages, without them having to manually change the project settings. I'll email GitHub support to see if that feature can exist :)

[daattali]

I moved the demo site into docs/ and removed the gh-pages branch. The README has been updated to recommend always using master and how to do it