Getting rid of master branch

[KirstieJane]

Heya! I was consulting with our Mozilla Science Lab advisors yesterday and was asking why we have two different branches, the gh-pages branch and the master branch. Their answer was that in some situations you'd have the code in master but the website information in gh-pages, but as we're building a website these two are one and the same thing. So we just don't need the master branch.

Therefore, it's going. I'm going to delete it this evening after the exec call. If you've forked the repository you're going to want to make sure that you end up in sync with this one after I've deleted the master branch. There are some instructions on the wiki to help you with this, but please reach out if you're having any problems.

Thanks!

[KirstieJane]

Tagging @erich001 @elizabethjm @neuroAmyo @grprtkal and @amitkumarj441 so you can object if this is a problem!!

[grprtkal]

Hi @KirstieJane ,

This was interesting to read. I'm still pretty new to Github and wasn't familiar with the interaction between master branch and Github pages.

An alternative would be to put the app or site code (using whichever framework/scaffolding tool we decide on like Yeomen or Meteor) on Master. That way we can all experiment with it by forking, cloning, pulling, etc. but also keep Github pages for what to show users until we have something production ready.

What do you think? Would this work?

[amitkumarj441]

Hi @KirstieJane ,

This is fine as it looks. I don't have any problem.
@grprtkal This might helps us in future for interacting with repo that we already have, even though i can also work for updating Github pages on week basis.
What all you say?

Cheers,
Amit Kumar Jaiswal

[KirstieJane]

Thanks for the feedback @grprtkal and @amitkumarj441. I agree - it does make sense to have a dev branch and a production (gh-pages) branch. I think calling the development branch master is misleading though, and at the moment everything is development!

I think I'm going to push ahead and get rid of the master branch so we just have one to work with now, but we can always create others (dev for example) in the future.

I'll wait until tomorrow to do this in case there are any big reasons not to!

[jvoytek]

I have never worked with a gh-pages branch, but I was reading this article from GitHub (https://help.github.com/articles/creating-project-pages-manually/) and it seems to me that the gh-pages branch is sort of an easy way to publish information to the general public about a project even if that project is private. It also does away with the github chrome (ui, etc that you would see on a README page for example (another way one might publish information about a project not through code)) that might be distracting to some audiences. However, I don't think it's meant to be used as a replacement for master or developing branches once we start developing the actual application, is it? I would see it being used in the mean time while the app (website?) is being developed, and then once the app is ready for prime time the gh-pages branch (and published website there) is replaced by a deployed app on a server somewhere (AWS anyone?).

[KirstieJane]

Thanks so much for all the details! I was talking about this with @acabunoc and when she has time she's going to post her thoughts here!

[abbycabs]

Hey all!

Lots of interesting directions this can go :) Here are my two cents, I hope this helps your community decide how to move forward.

On dev + master:

Yes, dev + master is a common development workflow and I think having some sort of dev branch is very smart! Great points @grprtkal & @KirstieJane.

The difference here (which @jvoytek has nicely pointed out) is that on GitHub, gh-pages is a magical branch that will also deploy your static site! It's powering your site here: http://kirstiejane.github.io/STEMMRoleModels/ and this makes it show up here, too: http://stemmrolemodels.com/

Given that you need gh-pages to power your current site, it doesn't make sense (to me) to continuously keep this up to date with your master branch. So, I suggested removing master altogether. I have no objections to adding dev if you want to!

On using a server instead of gh-pages:

Down the road, if you decide to use a server (for a database or server-side rendering, etc) then yes, you will outgrow gh-pages (and I ❤️ AWS, @jvoytek). Any server side development would ideally happen on a branch not named gh-pages, since it would break that magic. master would be an acceptable name.

On building your prototype on gh-pages:

However, given the scope of this project, I think you should be able to build a prototype web app on a static site (i.e. hosted completely gh-pages) using Google Spreadsheets / Google Forms / some fancy javascript.

Here's an example gh-pages site. Each 'Event Report' is taken from a google spreadsheet.
http://mozilla.github.io/clubs-events/

You can add a new 'Event Report' by filling out this form (go ahead! This is test data right now):
https://docs.google.com/a/mozillafoundation.org/forms/d/1TxqagaZED7DqroHN8obx0yr9n3A3pwl84_46rTER91c/viewform?c=0&w=1

Here is all the code & some explanations:
https://github.com/mozilla/clubs-events/

I would encourage you to go in this direction and learn from the example above since you already have a gh-pages site and google forms/sheets are relatively easy to use. This will get you up and running fairly quickly (I think luke built this in a week) - and the sooner you can show a working prototype to people, the better 😄

Note: If you have a contributor that is a database expert and can get you setup quickly, then by all means, skip the gh-pages site!

---

Sorry that was so long! I also wanted to say that I'm really impressed with how this work and community is coming together! There's been some amazing buzz and activity here, keep it up 👍 💯

[KirstieJane]

Right - I've deleted the master branch. For now, we're rocking just the ✨magical✨ gh-pages branch.

I'm going to put @acabunoc's comments in the wiki so we have them for reference. Any edit suggestions there are very welcome.