Confused creating nested branches in git

Question

I just started using git and started collaborating with other developers in the same code. I worked a bit with SVN, but I never had to collaborate with other people on my code base. Now that employees are working on the same code, I need an efficient workflow. When searching for such, I found this one , and it seems like a good workflow for our requirement.

My repository is on the local machine. I created a repository with git init --bare . I added the source codes for the wizards and clicked them. Then I added the "develop" git branch develop; git push -u origin develop using git branch develop; git push -u origin develop git branch develop; git push -u origin develop .

Now I want to create function branches from "develop", and I want these function branches to be accessible to all employees. I want to have a nested structure, something like this

 origin/master origin/develop origin/develop/newFeature origin/develop/anotherFeature etc. 

so when a co-author at git branch -a , he / she immediately finds out that “newFeature” is on the “develop” line and decides what to do.

So, after some trial and error, this is what I did:

 git clone file:///path/to/repo --branch develop git checkout -b newFeature develop EDIT some files git add . git commit git push origin newFeature 

This "newFeature" is now available for co-author cloning. git branch -a gives me

  develop * newFeature remotes/origin/HEAD -> origin/master remotes/origin/develop remotes/origin/master remotes/origin/newFeature 

So, is "newFeature" really part of a "developed" branch? Or is it now a branch in itself? Once I clone "newFeature", how can I check if this is a development line? Perhaps this can be confusing, as I can end up having a branch named "newFeature" in the mastery!

My understanding of how git works is definitely inadequate. Therefore, if someone can point me in the right direction, it will be great!

TIA

Answer 1

TL DR version: only git checkout -b develop/feature initially (for this you do not need to have a branch named develop !).

---

Branches do not actually "nest" for a ridiculously simple reason: the branch name (for example, newFeature ) just stands for some commit-ID, i.e. some SHA-1 "true name" of some commit.

(In this regard, the branch name matches the tag, for example, "v2.3".)

The thing that makes (local) branch names special, which sets them apart from any other link, is that "git checkout" will let you get "on a branch" by writing the branch name in git HEAD , and as soon as you do , creating a new commit will automatically update the branch name so that it points to the new command you just made.

(Deleted branch names cannot be retrieved "on" in this way, but their SHA-1 will also be changed as necessary. I mention this only because the next paragraph refers to "remote branches" or "remote tracking branches" that you see git branch -r in the output.)

The names of the branches are sorted, however, by git branch --list (after sorting by "type", that is, first group all local branches, and then all deleted branches). This means that you can group the names: just create the names as develop/anotherFeature and develop/newFeature initially. In this case, the slash is simply part of the name.

The problem is that git originally implemented these branch names ^{1 by} placing them in directories containing files. On systems supporting git, you cannot have a directory named develop and a file named develop at the same time. ² So, if you have a branch named develop , git may have created a file ( .git/refs/heads/develop , in particular), which then prevents it from creating a directory ( .git/refs/heads/develop , again ) containing the file ( newFeature ) containing the SHA-1 commit, which is currently identifying the branch.

---

¹ While git now also uses a flat file ( .git/packed-refs ) to store mappings from branches to SHA-1, it still also uses file directories and must make sure that you are not creating a name that should serve both the directory and the file.

² Personally, I think that the essence of a file system name makes sense to work both in a directory and in a file: this will be a way, for example, to store all ELF sections of an executable file as files in a directory that is an executable program, or to process what makes macOS for application packages. But this violates all kinds of rules for how things should work in POSIX, so this will require a major overhaul of the file system namespace and will be more suitable as a subsequent Plan 9 plan (for example) than as a Unix-ish variant.