Restrict branch creation? #1798
Replies: 1 comment
|
I support this proposal. In the Go ecosystem, Git branches have historically been more than just a development convenience—they're publicly addressable references that can effectively act as release channels, especially for legacy consumers and tooling. Restricting the upstream repository to release branches while encouraging all feature and experimental work to happen in forks helps keep the public branch namespace clean, makes the project's release policy clearer, and avoids exposing temporary or unsupported branches as if they were official. Since the proposal doesn't affect existing branches and only prevents creating new ones on the canonical repository, it seems like a reasonable governance improvement with minimal disruption to current workflows. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I want to discuss and possibly implement branch protection rules on Testify to restrict branches only to those which are releases.
In both Go Modules, and Go before modules (many of which still exist and import testify); a git branch is a de-facto release. For this reason it is considered good practice in many projects to disallow maintainers from pushing arbitrary branches to "origin" and instead require them to use a fork when opening pull requests. This is a practice that I have been following for many years now.
My proposal is to enable a branch ruleset for
*and not formasterwhich prevents creation of new branches. This would not affect existing branches which are still in use.All reactions