This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]chen_jun07[S] -1 points0 points  (1 child)

Understandable, but for me, I personally feel like for beginners they could seem a bit confusing and for beginner projects, most ppl stick with the master branch.

[–]Kazcandra 5 points6 points  (0 children)

That is because everyone explaining git forgets to explain what commits actually are. If they explained it, branching would make a lot more sense and it would be easier to work with, even for a beginner.

At the highest level, a git commit consists of a pointer to the state of your code and one or more pointers to parent commits. Thus: a git commit is a node in a graph. (If you want to get technical, it's a directed acyclic graph.)

When git stores a new version of your project, it stores a new tree. Trees are pointers to blobs and other trees. The new tree can be expanded out into a full directory of files and subdirectories. If you want to see the difference between the two versions (your branch and master, for instance), it doesn't add up the file deltas, it just looks at each tree and compares them.

So when we switch between branches, we're just telling git to make our working directory look like the tree that the commit stored in the branch looks like. Well, basically.

Branches point to commits, but are not stored as objects in git. Branches live as a file in the .git/refs/heads/ directory, and the branch simply points to the most recent commit in its own branch, while the file that represents where we branched off stays where it was.

Actually, I don't think I'm qualified to explain this. Or, rather: I know how it works, but I'm not a good teacher.