Reputation: 111
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 [email protected]: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?
Upvotes: 10
Views: 9511
Reputation: 61063
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."
Upvotes: 12
Reputation: 535139
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.
Upvotes: 4
Reputation: 76489
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.
Upvotes: 4