Git 2.28, released on July 27, 2020, lets development teams choose the initial branch name for new repositories without automatically renaming branches in existing projects. The new init.defaultBranch setting separates a preference for future starts from a migration of work already under way. That distinction matters when colleagues create a repository locally, join an established project or clone a project that is still empty: those are not all the same operation. [S1][S2][S4]

For a developer starting repositories with git init, GitHub’s release explanation gives the example git config --global init.defaultBranch main. It sets the user’s preference for the initial branch name; it does not announce a new universal Git default. In Git 2.28, an unset value still falls back to master. The version’s git-init manual also offers --initial-branch=<branch-name> for choosing a name when creating a particular repository. A team can therefore distinguish a standing preference from a choice made explicitly for one new project. [S2][S3][S4]

Existing shared work has a different boundary. GitHub explains that the configuration setting does not rename branches in existing projects. When cloning an established repository, Git continues to respect that repository’s HEAD, its indicated starting point, rather than imposing the developer’s preferred initial name. An upgrade and a configuration change are therefore not evidence that colleagues’ existing branches have moved. Changing an established project still requires a maintainer to initiate that change. [S2]

There is an important exception to treating clones as unaffected. Git’s own configuration documentation for version 2.28 says init.defaultBranch also applies when cloning an empty repository. A team testing only a populated project could miss that distinction: joining a project with an established branch and starting from an empty remote can produce different initial naming behavior. The useful onboarding instruction is to say which situation it covers, not merely to tell everyone to set the same preference. [S2][S4]

For team leads, the practical decision is whether the goal is consistent names for new work, a deliberate change to an existing project, or both. The setting helps with the first; it does not carry out the second. Keeping those decisions separate lets a team explain what will change for the next person creating a repository and what will remain unchanged for someone continuing an existing one. Neither the release notes nor the release explanation measures how much time that coordination will save. The documented benefit here is narrower: an initial name is configurable, while an existing project’s transition remains a separate task. [S1][S2][S3][S4]

Source documents

  1. Git 2.28 release noteshttps://raw.githubusercontent.com/git/git/v2.28.0/Documentation/RelNotes/2.28.0.txt
  2. GitHub: Highlights from Git 2.28https://github.blog/open-source/git/highlights-from-git-2-28/
  3. Git 2.28 git-init manualhttps://raw.githubusercontent.com/git/git/v2.28.0/Documentation/git-init.txt
  4. Git 2.28 init configuration documentationhttps://raw.githubusercontent.com/git/git/v2.28.0/Documentation/config/init.txt