Why do some Git branch names have slashes in them?

user_16247081 0
Viewed 3023

I'm reading this tutorial https://www.atlassian.com/git/tutorials/syncing/git-fetch

It contains an example where it adds a remote repo

git remote add coworkers_repo git@bitbucket.org:coworker/coworkers_repo.git

and then fetches a branch

git fetch coworkers_repo coworkers/feature_branch
fetching coworkers/feature_branch

In this last command, why the name of the branch name is "coworkers/feature_branch" has a forward slash? Shouldn't the branch be a string of characters such as "coworkers" or "feature_branch"? Or is there anything I'm missing?

git
3 Answers

Slashes are allowed (along with other special characters), and some Git UI software (such as SourceTree) will use them to group branches as if in folders. This results in something like so:

coworkers
  feature_branch1
  feature_branch2
customers
  feature_branch1
  feature_branch2

As Keith Thompson points out, "both one/two and one/two/three are valid branch names, but you can't have both in the same repo. Due to the way branches are represented in the .git directory tree, that would require one/two to be both a regular file and a directory."

user_12648040

There are a variety of characters that are allowed in a branch (or other ref) name, including the slash. In fact, a branch foo is really just a reference of the form refs/heads/foo. As such, adding more slashes is totally possible.

The reason people often use them is to roughly categorize their branches. For example, at work we share a single repository for our projects instead of using forks, so some developers prefer to create branches named username/branch to avoid conflicting with other users' branches. In addition, some projects prefer to categorize refs into groups like feature/*, bugfix/*, or hotfix/*.

The documentation for git check-ref-format outlines the valid formats. Because references are stored in the file system, there are some practical limitations to what can be in a ref. For example, you cannot have both branches foo (ref refs/heads/foo) and foo/bar (ref refs/heads/foo/bar) because in the former case foo would need to be a file and in the latter case it would need to be a directory. Also, if your file system is case insensitive or restricts certain byte sequences, that will often be reflected in whether you can store branches differing in case or using the byte sequences on your system.

There is a plan for a ref backend called reftable that doesn't suffer from these limitations, but it has not yet been implemented in Git.

user_87054320

What you're seeing is (a) legal and (b) a convention. How a team decides to name branches is up to the team. But there are a variety of popular and widely used conventions where slashes are used to categorize what the branch is about. See for example:

https://codingsight.com/git-branching-naming-convention-best-practices/

and especially

What are some examples of commonly used practices for naming git branches?

I would argue that your question is actually a duplicate of that, even though it was posed from a different angle.

I should add: the slash-based approach is so popular that many automated tools are based around it.

user_3419940
Related