Git from the Bottom Up - Commits

We are committed to continuing our deep dive into Git from the Bottom Up by John Wiegley, while Allen puts too much thought into onions, Michael still doesn't understand proper nouns, and Joe is out hat shopping.

The full show notes for this episode are available at https://www.codingblocks.net/episode192.

News

• Thanks for the review Alex Woodhead!
  • Want to help out the show? Leave us a review!
• Ludum Dare is a bi-annual game jam that's been running for over 20 years now. Jam #51 is coming up Sept 30th to October 3rd. (ldjam.com)
  • We previously talked about Ludum Dare in episode 146.

Commitment Issues

Commits

• A commit can have one or more parents.
  • Those commits can have one more parents.
  • It's for this reason that commits can be treated like branches, because they know their entire lineage.
  • You can examine top level referenced commits with the following command: git branch -v.
• A branch is just a named reference to a commit!
• A branch and a tag both name a commit, with the exception that a tag can have a description, similar to a commit.
  • Branches are just names that point to a commit.
  • Tags have descriptions and point to a commit.
• Knowing the above two points, you actually don't technically need branches or tags. You could do everything pointing to the commit hash id's if you were insane enough to do so.
• Here's a dangerous command:
  • git reset --hard commitHash – This is dangerous. --hard says to erase all changes in the working tree, whether they were registered for a check-in or not and reset HEAD to point to the commitHash.
• Here's a safer command:
  • git checkout commitHash – This is a safer option, because files changed in the working tree are preserved. However, adding the -f parameter acts similar as the previous command, except that it doesn't change the branch's HEAD, and instead only changes the working tree.
• Some simple concepts to grasp:
  • If a commit has multiple parents, it's a merge commit.
  • If a commit has multiple children, it represents the ancestor of a branch.
• Simply put, Git is a collection of commits, each of which holds a tree which reference other trees and blobs, which store data.
  • All other things in Git are named concepts but they all boil down to the above statement.

A commit by any other name

• The key to knowing Git is to truly understand commits.
• Learning to name your commits is the way to mastering Git.
  • branchname – The name of a branch is an alias to the most recent commit on that branch.
  • tagname – Similar to the branch name in that the name points to a specific commit but the difference is a tag can never change the commit id it points to.
  • HEAD – The currently checked out commit. Checking out a specific commit takes you out of a "branch" and you are then in a "detached HEAD" state.
  • The 40 character hash id – A commit can always be referenced by the full SHA1 hash.
    • You can refer to a commit by a shorter version of the hash id, enough characters to make it unique, usually 6 or 7 characters is enough.
  • name^ – Using the caret tells Git to go to the parent of the provided commit. If a commit has more than one parent, the first one is chosen.
  • name^^ – Carets can be stacked, so doing two carets will give the parent of the parent of the provided commit.
  • name^2 – If a commit has multiple parents, you can choose which one to retrieve by using the caret followed by the number of the parent to retrieve. This is useful for things like merge commits.
  • name~10 – Same thing as using the commit plus 10 carets. It refers to the named commit's 10th generation ancestor.
  • name:path – Used to reference a specific file in the commit's content tree, excellent when you need to do things like compare file diffs in a merge, like: git diff HEAD^1:somefile HEAD^2:somefile.
  • name^{tree} – Reference the tree held by a commit rather than the commit itself