Should we change default branch to master?

[rodrigoperazzo]

Since we're using dev branch as default and manually releasing things on master branch I can't automatically create a PR from dev to master because commit SHAs don't match and there is no option to override them (like a force). I would need to open master for pushes (from admins for instance) and push changes directly to master via terminal.

IMO this is a limitation of GitHub. Some companies use a branch model like that: feature + PR (OR a review tool like Gerrit which kind of replaces PR need), main (OR dev) and stable/master branches. Unifying all those concepts into the default branch can be a problem.

That said and understanding the effort to go against GitHub model, maybe we could go back and make master branch the default one and let release versions be the stable points which potential developers and users can rely on.

Please refer to this discussion: OriginProtocol/origin-js#123
And the GitHub flow: https://guides.github.com/introduction/flow/

[ehammo]

An interesting point in the attached discussion is this:

(We seldom actually break develop - the tests still pass, and things work. However any two origin repo's develop branches may not be in sync with each other, and thus cloning the current develop for each project has good odds of getting you a broken local system)

since we have 3 projects for sticky sessions, if a person download our 3 default branches (the dev branches) It might not work as expected, since our projects are not necessarily synchronized. But our masters (Stables) are (Or at least should be) in sync, since they are releases.

The only rule of github flow is:

anything in the master branch is always deployable.

So if we decide to change our default branch, how should we organize our stable points? Do you have an example of a repository that does this?

[micahalcorn]

We ended up moving to a monorepo and are loving it. 😁

[rodrigoperazzo]

Hi @micahalcorn Great! Did you guys observe any merging/rebasing/conflicts overhead after doing that? I mean, we may have distinct developers working on different sub-projects and they don't necessarily know about the other ones.

Even though, I like the idea of having everything in one place. We could try it.

Thanks for stopping by. =)