Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Why force designation of a remote main branch?
GitHub seems to require that one of the branches on it be marked as the "primary" branch. I understand this (perhaps mistakenly) to be the origin/HEAD. Why would they make it compulsory?
On forked repositories, I'm usually making branches and submitting pull requests. There's not really a "main" branch that I want to keep up-to-date. Yet GitHub makes me mark one.
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
As far as I can see, the GitHub documentation does not refer to a "primary" branch but it does refer to a "default" branch. This may seem like verbal nit-picking but I think it's an important distinction. The default branch isn't necessarily "more important" than other branches, it is just the branch that is used by default in a couple of places:
The default branch is the branch that GitHub displays when anyone visits your repository. The default branch is also the initial branch that Git checks out locally when someone clones the repository. Unless you specify a different branch, the default branch in a repository is the base branch for new pull requests and code commits.
As you correctly mention in your own answer, the default branch is used to determine what is shown by default in the web interface when someone visits your repo. Presumably it would be quite possible for the GitHub developers to implement additional UI to require visitors to explicitly choose a branch rather than just showing the default, but this would be extra development work for an unclear benefit.
The second usage ("the initial branch that Git checks out locally when someone clones the repository") is arguably far more important, because it is not within the control of GitHub developers. The Git tool requires a "currently active branch" in the remote repo, because this is what the git clone command checks out after cloning:
Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch --remotes), and creates and checks out an initial branch that is forked from the cloned repository’s currently active branch.
Since the Git tool needs a currently active branch, GitHub needs some mechanism to decide what this branch should be, and the current logic they are using is "first branch in the repo, unless the repo owner chooses a different one". Having no default branch at all is not really an option unless either (1) nobody is ever expected to clone the repo using the git command, or (2) the upstream Git developers can be persuaded that there is a use case for a repo with no active branch, and they agree to add handling for this case (e.g. by interactively prompting the user which branch to check out after cloning).
0 comment threads
These are my theories, but I'm not particularly excited about either of them.
Something to see
They need something to show when you visit the website's index. Otherwise, https://www.github.com/you/your-fork is a really boring page.
On the other hand, maybe it should be a boring page.
Something for comparison
They want to give visitors a meaningful ahead/behind summary.
Conversely, this is exactly the thing I'm annoyed by: If my main doesn't track upstream, GitHub is going to tell people I'm 600 commits behind and ignore the short-lived branches where the real activity happens.
0 comment threads
0 comment threads