Manage episode 336034321 series 2149378
After working with Git for over a decade, we decide to take a deep dive into how it works, while Michael, Allen, and Joe apparently still don’t understand Git.
The full show notes for this episode are available at https://www.codingblocks.net/episode190.
- Thank you for the new reviews DisturbedMime and Gjuko!
- Want to help out the show? Leave us a review!
Git Under the Covers
How to approach Git; general strategy
- This episode was inspired by an article written by Mark Dominus.
- Git commits are immutable snapshots of the repository.
- Branches are named sequences of commits.
- Every object gets a unique id based on its content.
- The author is not a fan of how the command set has evolved over time.
- With Git, you need to think about what state your repository is in, and what state you would like to be in.
- There are likely a number of ways to achieve that desired state.
- If you try to understand the commands without understanding the model, you can get lost. For example:
git resetdoes three different things depending on the flags used,
git checkouteven worse (per the author), and
- The opposite of
- Possibly the worst part of the above is if you don’t understand the model and what’s happening to the model, you won’t know the right questions to ask to get back into a good state.
- Mark said the thing that saved him from frustration with Git is the book Git from the Bottom Up by John Wiegley (jwiegley.github.io)
- Mark doesn’t love Git, but he uses it by choice and he uses it effectively. He said that reading Wiegley’s book is what changed everything for him. He could now “see” what was happening with the model even when things went wrong.
It is very hard to permanently lose work. If something seems to have gone wrong, don’t panic. Remain calm and ask an expert.Mark Dominus
Git from the Bottom Up
- A repository – “is a collection of commits, each of which is an archive of what the project’s working tree looked like at a past date, whether on your machine or someone else’s.” It defines
HEAD, which identifies the branch or commit the current tree started from, and contains a set of branches or tags that allow you to identify commits by a name.
- The index is what will be committed on the next commit. Git does not commit changes from the working tree into the repository directly so instead, the changes are registered into the index, which is also referred to as a staging area, before committing the actual changes.
- A working tree is any directory on your system that is associated with a Git repository and typically has a
.gitfolder inside it.
- A commit is a snapshot of your working tree at some point in time. “The state of HEAD (see below) at the time your commit is made becomes that commit’s parent. This is what creates the notion of a ‘revision history’.”
- A branch is a name for a commit, also called a reference. This stores the history of commits, the lineage and is typically referred to as the “branch of development”
- A tag is also a name for a commit, except that it always points to the same commit unlike a branch which doesn’t have to follow this rule as new commits can be made to the branch. A tag can also have its own description text.
- master was typically, maybe not so much now, the default branch name where development is done in a repository. Any branch name can be configured as the default branch. Currently, popular default branch names include main, trunk, and dev.
HEADis an alias that lets the repository identify what’s currently checked out. If you checkout a branch,
HEADnow symbolically points to that branch. If you checkout a tag,
HEADnow refers only to that commit and this state is referred to as a “detached
- The typical work flow goes something like:
- Create a repository,
- Do some work in your working tree,
- Once you’ve achieved a good “stopping point”, you add your changes to the index via
git add, and then
- Once your changes are in the state you want them and in your index, you are ready to put your changes into the actual repository, so you commit them using
Resources We Like
- Things I wish everyone knew about Git (Part 1) (blog.plover.com)
- Git from the Bottom Up by John Wiegley (jwiegley.github.io)
- Orthogonality (Wikipedia)
- Version Control with Git: Powerful tools and techniques for collaborative software development (Amazon)
- Comparing Git Workflows (episode 90)
- Designing Data-Intensive Applications – SSTables and LSM-Trees (episode 128)
Tip of the Week
- Celeste is a tough, but forgiving game that is on all major platforms. It was developed by a tiny team, 2 programmers, and it’s a really rewarding and interesting experience. Don’t sleep on this game any longer! (CelesteGame.com)
- Enforcer Maven plugin is a tool for unknotting dependency version problems, which can easily get out of control and be a real problem when trying to upgrade!
- Tired of sending messages too early in Slack? You can set your Slack preferences to make
ENTERjust do a new line! Then use
CMD + ENTERon MacOS or
CTRL + ENTERon Windows to send the message! Thanks for the amazing tip from Jim Humelsine! (Slack)
- Using Docker Desktop, and want to run a specific version? Well … you can’t really! You have to pick a version of Docker Desktop that corresponds to your target version of Kubernetes!
- Save a life, donate blood, platelets, plasma, or marrow (redcrossblood.org)
- What if you want to donate blood marrow or cord blood? You need to be matched with a recipient first. Check eligibility on the website at Be The Match. (bethematch.org)
- Also, not quite as important, you can disable all of the stupid sounds (bells) in WSL!
- Disable beep in WSL terminal on Windows 10 (Stack Overflow)