{"id":3383,"date":"2024-01-15T02:15:00","date_gmt":"2024-01-15T07:15:00","guid":{"rendered":"https:\/\/www.both.org\/?p=3383"},"modified":"2024-01-09T15:39:17","modified_gmt":"2024-01-09T20:39:17","slug":"git-concepts-in-less-than-10-minutes","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=3383","title":{"rendered":"Git concepts in less than 10 minutes"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n 1 <\/span>\r\n<\/div><\/div>\n

Git<\/a>\u00a0has become the default way to store and transport code in the DevOps generation. Over 93% of developers report that Git is their primary version control system. Almost anyone who has used version control is familiar with\u00a0git add<\/code>,\u00a0git commit<\/code>, and\u00a0git push<\/code>. For most users, that\u2019s all they ever plan to do with Git, and they’re comfortable with that. It just works for their needs. <\/p>\n\n\n\n

However, from time to time, almost everyone encounters the need to do something a little more advanced, like git rebase<\/code> or git cherry-pick<\/code> or work in a detached head state. This is where many devs start to get a bit nervous.<\/p>\n\n\n\n

I’m here to tell you it is ok! Everyone who has or will ever use Git will likely go through those same pangs of panic.<\/p>\n\n\n\n

Git is awesome, but it’s also intimidating to learn, and it can feel downright confusing sometimes. Git is unlike almost anything else in computer science. You typically learn it piecemeal, specifically in the context of other coding work. Most developers I have met have never formally studied Git beyond perhaps a quick tutorial<\/a>.<\/p>\n\n\n\n

Git is open source, meaning you have the freedom to examine the code and see how it works. It’s written mainly in C which, for many devs and people learning computer science, can make it hard to understand. At the same time, the documentation uses terms like massage parameters<\/a> and commit-ish<\/a>. It can feel a little baffling. You might feel like Git was written for an advanced Linux professional. That is because it originally was.<\/p>\n\n\n\n

A brief Git history<\/h2>\n\n\n\n

Git started as a specific set of scripts for Linus Torvalds to use to manage patches.<\/p>\n\n\n\n

Here’s how he introduced what would become Git to the Linux kernel mailing list<\/a>:<\/p>\n\n\n\n

\n

So I’m writing some scripts to try to track things a whole lot faster. Initial indications are that I should be able to do it almost as quickly as I can just apply the patch, but quite frankly, I’m at most half done, and if I hit a snag, maybe that’s not true at all. Anyway, the reason I can do it quickly is that my scripts will _not_ be an SCM, they’ll be a very specific “log Linus’ state” kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible.<\/p>\n<\/blockquote>\n\n\n\n

One of the first things I do when I get confused about how Git works is to imagine why and how Linus would apply it to managing patches. It has grown to handle a lot more than that and is indeed a full source code management (SCM), but remembering the first use case is helpful in understanding the “why” sometimes.<\/p>\n\n\n\n

Git commit<\/h2>\n\n\n\n

The core conceptual unit of work in Git is the commit. These are snapshots of the files being tracked within your project folder ( where the .git<\/code> folder lives.)<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

It’s important to remember that Git stores compressed snapshots of the file system, not diffs. Any time you change a file, a whole new compressed version of that file is made and stored in that commit. It does this by creating a super compressed Binary Large Object (blob) out of the file, and then keeping track of it by generating a checksum made with the SHA hashing algorithm. The permanence of your Git history is one of the reasons it’s vital never to store or hardcode sensitive data in your Git projects. Anyone who can clone the repo<\/a> has full access to all<\/strong> the versions of the files.<\/p>\n\n\n\n

Git is really efficient. If a file does not change between commits, Git does not make a whole new compressed version for storage. Instead, it just refers back to the previous commit. All commits know what commit came directly before it, called its parents. You can easily see this chain of commits when you run git log<\/code>.<\/p>\n\n\n\n

\"Image<\/figure>\n\n\n\n

You have full control over these chains of commits and can do some pretty cool things with them. You can create, delete, merge and reorder them as you see fit. You can even effectively travel through time, explore and even write your commit histories. But it all relies on understanding how Git sees chains of commits, which are generally referred to as branches.<\/p>\n\n\n\n

Git branches<\/h2>\n\n\n\n

Branching<\/a> lets you work with multiple chains of commits inside a project. Working with multiple branches (especially when you work with rebase<\/code>) is where many users start to sweat. A common mental model most people have about what branches even are adds to the confusion.<\/p>\n\n\n\n

When thinking about branching, most people conjure up images of swim lanes, diverging, and intersecting dots. While those models can be helpful when understanding specific branching strategies and workflows, thinking of Git as a series of numbered dots on a graph can muddy the waters when trying to think about how Git does what it does.<\/p>\n\n\n\n

An alternative mental model I find helpful is to think of branches existing in a big spreadsheet. The first column is the parent commit ID, the second is the new commit ID, and then there are columns for metadata, including all the pointers.<\/p>\n\n\n\n

\"Image<\/figure>\n\n\n\n

Pointers keep track of where you are, and which branch is which. Pointers are convenient human-readable references to specific commits. Any reference that leads back to a specific commit is referred to as commit-ish.<\/p>\n\n\n\n

The special pointer used to name a branch always points to the newest commit on the chain. You can arbitrarily assign a pointer to any commit with git tag<\/code>, which doesn’t move. When you git checkout<\/code> or git switch<\/code> between branches, you’re really telling Git that you want to change the point of reference of Git and move a very special pointer called HEAD in every .git<\/code> folder.<\/p>\n\n\n\n

The .git folder<\/h2>\n\n\n\n

One of the best ways to understand what is going on with Git is to dig into the .git<\/code> folder. If you’ve never opened this file before, I highly encourage you to open it up and see what’s there. If you’re very nervous you might break something, clone an arbitrary open source project to play around with until you feel confident to look into your own project repos.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

One of the first things you notice is how small the files are.<\/p>\n\n\n\n

Things are measured in terms of bytes or kilobytes, at the largest. Git is extremely efficient!<\/p>\n\n\n\n

HEAD<\/h3>\n\n\n\n

Here in the .git<\/code> folder, you find the special file HEAD. It’s a very small file, only a handful of bytes in size. If you open it up, you see it\u2019s only one line long.<\/p>\n\n\n\n

git > HEAD\n  ref:refs\/heads\/main<\/code><\/pre>\n\n\n\n
One of the phrases you will often encounter when reading about Git is “everything is local.” From Git’s perspective, wherever HEAD is pointing is “here.” HEAD is the point of reference for how Git interacts with other branches, other refs, and other copies of itself.<\/p>\n\n\n\n
In this example, the ref:<\/code> is pointing at another pointer, a branch name pointer. Following that path, you can find a file that looks much like the spreadsheet from earlier. Git just takes the latest commit ID from the file and knows that is the commit HEAD is referring to.<\/p>\n\n\n\n
If HEAD refers to a specific commit with no other pointer attached, then HEAD is referred to as “detached.” Working in a detached HEAD state is completely safe, but limits what you can do, like make new commits from there. To get out of a detached HEAD state, just checkout another pointer, like the branch name, for example, git checkout main<\/code>.<\/p>\n\n\n\n
Config<\/h3>\n\n\n\n
Another critical file for helping Git keep track of things is the .git\/config<\/code> file. This is just one of the places Git leads and stores configuration. You’re likely already familiar with the --global<\/code> level of Git config, stored in your home directory in your .gitconfig<\/code> file. There are actually five places Git loads config, each overriding the previous configuration. The order Git loads config is:<\/p>\n\n\n\n