Renaming master branch to main

[pcrumm]

There's been a healthy amount of recent discussion in the tech community (eg) surrounding the usage of "master" in version control nomenclature given the term's insidious background. Recognizing that the words we choose (even implicitly) matter, and given the relatively marginal level of effort required to make this adjustment, I suggest that we deprecate the usage of the term in 10up's open source projects and replace it with "main".

To do so, we'll need to:

• Rename the master branch in 10up's actively maintained open source repositories to main
• Update the default branch setting in each project's Github settings
• Update any associated Github Actions
• Update this repository's documentation

I'm creating this as an issue to encourage discussion and to seek others' input, particularly surrounding the new primary branch naming convention (is main the right term?) – with that said, please be mindful of the code of conduct when contributing.

[jeffpaul]

@pcrumm I ran across some similar commentary this morning and agree with you, mainly curious if @helen or anyone else has particularly strong opinions in the new branch name (main, primary, origin, source, etc.). I also want to scan through our repos to see if we have any references to blacklist/whitelist as well, but will handle that separately from this issue. Note that our default branches should all be set to develop at this point, but its worth validating that as we go through and update branch naming.

[helen]

I would like to move off of master naming.

That said, at this moment I am not personally a fan of main and would prefer to gauge the direction of communities at large for a little longer before declaring X a "best practice". For our own repositories, most of them should use develop as the default already, and master would be better served being named something more descriptive of how a project is running like stable or trunk or what have you.

[jeffpaul]

Quick update that current approach is to rename to trunk.

[jeffpaul]

It appears for GitHub Pages-powered sites the branch option appears to only be gh-pages so this repo won't update to trunk but instead to gh-pages until GitHub allows alternate branch names for GitHub Pages.

[benlk]

GitHub pages can now build and deploy from any branch: https://github.blog/changelog/2020-07-31-build-and-deploy-github-pages-from-any-branch-beta/

Repositories that use GitHub Pages can now build and deploy from any branch. Publishing to the special gh-pages branch will still work the same as it always has, but you can now choose a different branch in your repository as the publishing source. This functionality also removes the hardcoded dependency on user and organization pages having a master branch.

The docs at https://docs.github.com/en/free-pro-team@latest/github/working-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site#choosing-a-publishing-source have been updated to document the branch selector in Settings > Github Pages.

[davidegreenwald]

@jeffpaul There is a master reference in https://10up.github.io/Open-Source-Best-Practices/github-process/ which could be updated to trunk. Noting too that GitHub and GitLab are both now using main.

[jeffpaul]

@davidegreenwald yeah that's covered in #63, I'll look to adjust for changes in the hookdoc file and then merge that PR... thanks!

[jeffpaul]

Docs have been updated in this repo, I have otherwise been making branch updates across all other repos as (1) we ship a new release or (2) I have time to ad hoc make those changes. I'd be happy to review/merge PRs from other folks that update references in other repos and then make the respective branch changes at the repo level for any other repos I haven't gotten to you; noting that plugins are using trunk and other projects are using stable.