Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. Understanding and mastering this feature gives you a powerful and unique tool and can entirely change the way that you develop.
When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
So it looks something along these lines
struct Commit
author_name::string
author_email::string
ptr_to_snapshot::pointer
ptr_to_parent_commits::pointer
end
To get a visual image let’s say you add files and commit
$ git add README test.rb LICENSE
$ git commit -m 'Initial commit'
Git does some work and then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.
Your Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata.
A commit and its tree
Every time you make commits you add one more commit object to commit tree that points to its predecessor.
The default branch name in Git is main. As you start making commits, you’re given a main branch that points to the last commit you made. Every time you commit, the main branch pointer moves forward automatically
This is what a branch and its commit history looks like
