When the entire structure of commits is called a tree, I find the name "branch" fitting. The branch is identified by its head commit, so the path from head to root is uniquely defined and that's the branch. (Disregarding merges for now.)

Leaning into the tree metaphor (and following the precedent of other version control systems), git should have used the term trunk instead of master or main.

Why? That would heavily imply that master/main is somehow technically different from all other branches (since a trunk is certainly not a branch), which to my knowledge is not true.

I see what you mean, but don't "master" and "main" also imply some special authority? Trunk-based development with branches forking off and merging back into the trunk (a DAG, unlike a real tree! :) is an extremely common workflow.

https://trunkbaseddevelopment.com/

By following this metaphor, a trunk would be the original commit, whereas branches are the tree branch tips.

And consider that because every folder can have its own .git subfolder, we can have several paralle trunks/repositories at the same time, meaning we have a forest.

I haven't really seen specific guidelines as to when and why should anyone start a new repo. Are there some? Or is "mono-repo" the best solution, and when and for whom. Surely we need more than one git-repo in the whole world?!

> Disregarding merges for now.

Without disregarding them, it's not a tree, but a DAG.

It is a tree. What makes you think it's just a DAG? Are there commits with multiple parent commits or what?

There absolutely can be. Merge commits have multiple parent commits for example. It's definitely a graph not just a tree.

Parent comment was about disregarding merge commits.

You can't disregard merge commits. It's part of the structure.

Yes. Merge commits have two parents.

Two or more. I'm not sure there's a limit.

Try not to do this (imagine a 5-way merge conflict).

FWIW “tree” has a specific, different meaning in Git. It’s a file tracking the contents of a directory.

Well yes if you disregard the thing that makes it not a tree then it is a tree. But you can't disregard that!

That's (most probably) where the "head" terminology comes from, too.

Yes you are correct. It traces back to Allen Newell

> Git was made by C people and they’re used to referring to entire data structures by way of some root element.

FWIW this is actually backwards. The word "branch" was already in common use (to refer to the same basic idea) in SCM systems going back decades, and in almost all of those a "branch" was indeed a first class object with its own data that acted as a "container" for commits, both semantically and physically.

The fact that a "branch" is just a pointer is in fact a git innovation on top of the former idea.

> acts more like a bookmark

In fact, Mercurial uses the term “bookmark” for its lightweight, git-like branching. Mercurial’s branches have slightly different semantics and can’t be deleted like bookmarks or git branches

> Git was made by C people

This is why I think of branches as pointers. The file contents are literally just a pointer to a commit on the DAG.

I don't see the problem?

Real natural tree branches grow.

If you move the branch to point somewhere else, then it's better/more accurately said that you changed the name to refer to a different branch. We can think of branches as the chains of commits; it's the names we give them that 'wander' both as we commit and if we move them to a different branch. But merging (as it were!) the concepts of branches and names for their tips is convenient, and often equivalent/inconsequential.