What is Git

[00:00:00]
>> Git is a distributed version control, which is much different, at one point in time, we used to have a centralized version control system. Which meant that I would check out file A, and if I happened to go on vacation, you could just never edit file A, that was mine, it's mine until I check it back in.

[00:00:15]
And this is most people's, development style up until till we started having distributed versions, the thing that's awesome about git, is that you have your version. Your version doesn't have to represent the reality of some remote version. It's just your version until you wish to update it till you wish to sync and so that's what makes git so dang good.

[00:00:38]
In git, there's kind of two levels of commands, there's the porcelain commands and then the plumbing commands. We're gonna go over mostly porcelain commands, but we will get down to the plumbing. We will kind of try to understand how git works and hopefully the big takeaway from this course is that you understand how gits data structure works.

[00:00:58]
So that way you don't feel confused when you use it. When you use rebase or you revert or you cherry pick any of those things, you understand how these things work, and therefore it's simple, nothing hard about it. Some key terms I'm gonna use the term repo, a repo simply means a project rocked by git.

[00:01:17]
It's a folder or I use folder because I grew up with windows, that's just how it works. It's a directory, some people call it a directory and are offended when I use the term folder. Either way, you'll see me use those two terms, but a repo is just simply something with a get folder in it.

[00:01:30]
That means it's being tracked actively by git, and if you're on windows, I don't know exactly how it looks if you're on just actual windows, not WSL two. And so I assume, it's probably the same thing, some sort of hidden folder that exists on Windows that tracks all your stuff, I don't know.

[00:01:46]
A commit is just simply a point in time representing the project in its entirety. Now, for those that are somewhat familiar with Git, that might be a bit surprising. You probably think that it stores differentials, it's here's from one change to the next. No, every single commit is the entirety of the code base, and it can be regenerated from that one and single commit.

[00:02:09]
So kind of always a little bit of a shocker, and commits are often denoted by a 40 character, a through f, zero through nine hexadecimal kind of string. And that's going to be based off the contents of the change, the author, the time, everything. I'll often use the term index, this can be kind of interchangeably used with staging.

[00:02:29]
Staging is the area in which you prepare the changes you wish to commit, and when you commit, anything in the staging area or the index will be committed. So if you have unstaged items, they won't be committed, they'll remain red. That's why you can kind of pick one file to commit not the other one, it's because there is a staging area.

[00:02:50]
I will probably toss out the term squash at some point, which really means to take a commit or to take two commits and turn it into one commit. That's squashing by one level, you can take N commits and turn it into N minus one or less commits, that'd be an act of squashing.

[00:03:05]
If I say the term work tree, working tree, main working tree, this is your get repo. You'll see it a lot in the documentation, this term working tree all the time. Working tree is just the fancy term for your stuff, it's what is being tracked by git and has some sort of history in it.

[00:03:22]
I'll use the term untracked, staged and tracked, I could use effectively, let's go to ExcaliDraw for a quick second. But the easiest way to kinda describe it is that at some point when you're using git, there exists all of your files, right? You haven't done anything, you haven't added it, this is the untracked kind of region.

[00:03:41]
Then at some point, you're going to want to start tracking them, and so you track them by adding them to the index. And so that's why when I say staging, this is what I mean by that, let me get a better color, let's call, I guess brown, we'll go with brown, that's a pretty nice color.

[00:03:57]
So this is your staging area, staging is just simply git being ready, and this is always every single flow you'll ever have. You'll have some sort of untracked file that becomes staging, and then once it becomes staging. It's gonna go one more time when you commit and then it's fully tracked by git with a history, and so it's kind of a three-step process anytime you're using git.

[00:04:18]
And so if you don't have this kind of picture in your head, I think you'll find get to be more difficult. You have not tracked I'm tracking, but I'm not committed, I'm committed, and long as you kind of look at it in that way, it will make sense.

[00:04:29]
And once you've added a file, then you get new possibilities because git know that it already exists. So when you add a change, you're in this tracked, but not staged cycle, makes things a little bit easier to kind of think about if you just always keep that picture in your head.

[00:04:46]
All right, and then let's see, yeah, we've already talked about all three of those, so fantastic. Some key facts about git is that git is an acyclic graph, if you don't know what an acyclic graph, take free data structures course on frontend masters, am I right? Everybody frontendmasters.com slash courses slash algorithms you may have heard of it, it's pretty fantastic, and get every commit is a node in the graph.

[00:05:08]
And each pointer is a child-parent relationship, meaning that you can have more than one parent, but you cannot have a cycle in the graph. I wouldn't even know how you would commit a cycle in the graph, it just doesn't make any sense, if you delete untracked files, they are just lost forever.

[00:05:25]
That is your bad, there's that hilarious Github post where someone yells about losing 5,000 files. Because they didn't realize that if you don't have something tracked, it will go bye bye forever. So make sure you know that about Git if you delete a file, that could be it, bye.

[00:05:40]
Second, always, man git dash, start there, read the friendly manual, most of it's pretty good. Some of it still sucks, I actually don't even understand when I read a man git-tag. I still don't really know what's happening when I read it, it's kind of just it's It feels strange to read, so sometimes you gotta go on the internet.

[00:06:01]
But for the most part, it's pretty good, I know that a lot of you probably just have these five commands. So this is kind of the typical git experience, push, pull, add, commit and status. Everything else mysterious, painful in this course, my goal is either you have zero knowledge or around that knowledge.

[00:06:17]
And we want to take it a step further to where you can use most features of git easily. The reality is if you're comfortable with rebase, reread, reflog, log, cat file, config and reset, this course might not be for you. Just real talk, if you're already pretty that far into git, I don't think you're going to get a whole bunch out of this.

[00:06:36]
And so, I don't want you to get your hopes up that we're actually going to be making git, we're gonna be going over it and making you practically useful. Because the hardest part about working on a job is usually never the code itself, it's the poor decisions you've made in the past about the code.

[00:06:53]
And then second, working with some sort of version control with everybody else. So once you get past that first part about you being a bad programmer, don't worry, I'm a bad programmer too we're all bad programmers. But after that it's just being able to be effective with 40 people all committing to one code base, and there's a lot of strategy there.

[00:07:10]
And the worst part is when you have to revert and no one has a git policy and it becomes impossible to revert your change due to merge commits. How many different little tiny commits that are all interweaved and it becomes a nightmare, so we're gonna hopefully have some sort of sense about git by the end of this.