Provide separate settings for default view branch vs. default PR base branch #7834
Replies: 2 comments
-
It's not an issue for the repositories with a small number of users who are not contributors, but it's a really difficult choice for repositories that have users (particularly if you suggest building from source)... The additional problem is that you cannot see which branches are aligned with the main development branch, and which are are ahead/behind, as it is all compared with the public view branch... So, while directly this feature is needed by a small number of users (hence a relatively small number of upvotes), these are the users who maintain the most adopted projects, so indirectly it would benefit a very large number of github users via the improved ergonomics for the maintainers - and it should be a relatively simple feature to add :) |
Beta Was this translation helpful? Give feedback.
-
This is still an issue in 2024. I would comment that even small projects can be more user-focused, with one or maintainers supporting a larger number of users (who are not contributors). For example, keeping up a PyPI release, the default for readthedocs, and the github default view consistent is an important goal for a Python-based project. This more or less implies having a stable "main" branch which is only updated when releases occur, and having development occur on a "develop" branch. Other names may be chosen (e.g. develop on main and use "release" or "stable" for the default branch) but the implication is the same. This means making the default branch in github "main" (or release/stable). The cost is the extra development complexity when developers frequently rely on the default, and create merge requests to main rather than to "develop". This could also result in inadvertent merges to the main/stable branch if the maintainer overlooks that aspect of a merge request. |
Beta Was this translation helpful? Give feedback.
-
Re-posting from this popular github issue
Currently GitHub has a single default branch setting, which affects both the code/documentation that is seen when users reach the repository, as well as the default base branch for new pull requests.
It would be supremely helpful if these two things could be set separately, so that you can configure a repository's default view branch to align to the latest release, while leaving its default PR branch at master for new development.
Currently, setting the default branch to the latest release results in really poor ergonomics for PRs if you forget to adjust the base branch before sending them. You're likely going to end up with spurious check failures (e.g. a CLA failing because of a confused commit history) or checks not running at all (e.g. Travis being configured to run against master), requiring pushing dummy commits to fix even after adjusting the base branch.
Beta Was this translation helpful? Give feedback.
All reactions