@onebree solved a first item. #169

that way you think to solve this?

• Manually merge other PRs into gh-pages branch (not currently selected)

@vtorves I need to review your pull request. I appreciate what you've done so far to help us out in this transition.

As far as the second task, that is something I would rather a maintainer to complete. There are likely to be merge conflicts because of the new site.

@andreareginato any thoughts on changing the default branch to gh-pages? I mean, do we even need master? Just curious. The only experience I have with GH Pages is when it comes from username.github.io, in which master is the only branch. (Personal, not project pages)

I recommend this proposed change.

Dan Kohn mailto:dan@dankohn.com
tel:+1-415-233-1000

On Fri, Feb 19, 2016 at 8:19 AM, Hunter Stevens notifications@github.com
wrote:

@andreareginato https://github.com/andreareginato any thoughts on
changing the default branch to gh-pages? I mean, do we even need master?
Just curious. The only experience I have with GH Pages is when it comes
from username.github.io, in which master is the only branch. (Personal,
not project pages)

—
Reply to this email directly or view it on GitHub
#168 (comment)
.

Simplification should be the driver. +1

@andreareginato I do not have permissions to change the repo's settings -- this is something that you need to do. I can only delete or create branches. Not change which is default

@onebree you and @akz92 are now admin. Let me know if you have the right permissions.

@benoittgt I am assigning this issue to you. Here is how I would go about things:

1. Fork lelylan/betterspecs off of gh-pages branch
2. Checkout a new branch prs-in-gh-pages
3. For the PRs: Fix 'RSpec' capitalization #135, Update books.html #137, Fix "Easy to read matchers" index entry to match section title #138, Fix Spanish and French versions of 'guard' section #164
   1. Create a remote for the author branch on the PR.
   2. git merge --no-commit <remote> <branch>
   3. Review the changes, fix any merge conflicts, etc
   4. Create 1 commit per PR fixed
4. Submit 1 PR against gh-pages, containing all these changes, include the main comment: Closes #135, closes #137, closes #138, closes #164
5. Another person can review the changes to make sure everything is good, then submit the PR.

@benoittgt can you work on the last 2 tasks listed in this issue?

• Add blurb in CONTRIBUTING about choosing the gh-pages branch. Even though it is currently the default, some people may still try to choose master.
• Research whether we need the master branch at all.
  • If we do not need it, I will take it from there -- I want to make sure all the help from everyone is not lost, and that the commit history is maintained.
  • If we do need a master branch, then its current state should be copied to a new branch heroku. From there, I will then clear out everything in master, except for READMEs, etc.

For the gh-pages branch this for me not a problem expect the thing we should have a README. :)

@benoittgt of course there should be a README. But did you research whether a project-page/repo can live without a "master"-named branch?

@onebree I did some research about "master" branch but didn't found something relevant. On Pro Git 2nd Edition by Scott Chacon and Ben Straub we can read this... but that's all.

@benoittgt Alright -- I will look into doing a quick merge this week, so gh-pages contains all master commits.