From Pluralsight course "How Git Works"
If you don't want to get into trouble, understand the conceptual model.
Layers:
Distributed revision control
Revision control system
Stupid content tracker
Persistent map (the core)
The entire object model:
Blobs
Trees
Commits
Annotated tags
A commit is a SHA'd object that stores the SHAs of trees and blobs as well as the parent commit, author and date and commit message.
A branch is just a reference to a commit. Nothing more.
HEAD is just a reference to a branch. Or a reference to a commit if you checked out a commit, in this case the HEAD is a detached HEAD.
Checkout changes HEAD to point to the branch being checked out, and the working area is changed to the files represented in the commit referenced in the branch object.
A tag is like a branch that doesn't move.
Detached HEAD:
Checkout any commit. Now you can work in a "detached way" like a spike. If you don't create a branch off a detached commit Git will garbage collect all the detached commits eventually.
Three Rules:
1) The current branch tracks new commits.
2) When you move to another commit, Git updates your working directory.
3) Unreachable objects (those that are not reachable via a branch, HEAD or a tag) are garbage collected.
Rebase:
When in doubt, just merge. Only rebase if you know what you're doing and are fully aware of any consequences.
Command reference:
git show-ref <branch> this will show the contents of the branch file which is a reference to a commit but will show both the local branch and remote so you can see if there is a difference. If the commits are the same, then the local and remote are synchronized.
git cat-file -p <sha>
to show contents of a commit. Don’t need to be in the objects subdirectory.
But you do need to put the 2 char folder name as prefix to the file name
