So now that we know that Git is a version control system, a popular one at that, let's talk more about
the specific features.
What does it do for us?
So in this slide we can see some of the main things get helps us with it helps track changes across
files, compare versions of a project, time travel back to old versions.
Take a peek at what something looks like a year ago.
Take a look at Facebook's code base today compared to two days ago.
Go back to a previous version if we messed something up, combine different changes between versions,
between different files, between different collaborators.
And that's probably the most important part.
Collaborate and share changes get facilitates collaboration between a team of users.
If developers of writers, whatever people are doing with Git Get facilitates collaboration and sharing
those changes between individual people.
So here's a very, very simple explanation.
If you've ever played video games like I have, there are some games that allow you to make save points
that will check points you can come back to.
And I guess this is supposed to be me.
I was always very, very nervous as a game player.
Some of the games I played as a kid where if you died, you would go all the way back to wherever your
last save was.
So I would always try and save before well, pretty much before anything.
So I would save and then get to some horrible boss battle.
I suck at video games even though I like them.
I die.
But that's okay.
I don't get angry because I saved my game.
I can just go back to that save point.
That is the simplest, simplest explanation of JIT and what it allows us to do.
Set up these checkpoints.
You can screw things up entirely, make a huge mess of a code base or of a project, empty all the files
out, delete the files.
But if you're using Git and you made these checkpoints, you can just go back.
So here's another explanation that I've used in high school.
In college I had to write a lot of essays.
I did not know Git really at the time.
So I did this.
I would start writing an essay and then I wanted to try something new so I'd save as I'd make a new
version that was V one or V two or even more variations v two with a new intro or a new conclusion or
reorder all sorts of different strategies.
And I would save all of them because I wanted to be able to compare.
I didn't want to just have one essay that I had to work in.
I want to be able to track versions and compare, and it's just part of the process.
And then I would end up with some final, but then inevitably actually final, final for real.
This is the one print, this one.
This was honestly what I did in high school and college all the time.
So get helps with this sort of issue.
Now this is a very trivial situation, but imagine thousands of developers collaborating on a project
where they're working on millions of lines of code all at the same time, and having these different
versions and sharing and combining them.
So here's a somewhat more realistic example.
I'm working on some project, a website.
This is the progress of the website up top.
So right now it's empty.
With Git, I create checkpoints, so checkpoints are like save files I can go back to.
So I have my first checkpoint initialize project.
There's nothing up there.
But then I do some work.
I add this nav bar up top, so I make a new checkpoint, add top nav bar.
Now I have two checkpoints and then I do more work, write some content.
So I add a new checkpoint.
We'll say Add first row, whatever this is.
Maybe I'm making YouTube or something, so I add some content and then I do more work, I add more content,
I add a new checkpoint.
This workflow is very, very common.
You do something in a project.
If you're using Git, you make one of these so called checkpoints.
We'll learn what they are and how you do it, of course, and then you keep working.
So here I changed the theme entirely.
A dark theme, new fonts, new colors, new everything.
I add a checkpoint.
So I forgot to mention I work not alone on this.
I'm working at a company.
I have a boss.
I'm not the one making these decisions.
Right?
What stays if we want this theme or not, or if we want this earlier theme here.
But anyway, I do some more work.
I alter the naff bar color, I make it yellow, I add a checkpoint, update nav bar, and then I show
it to my boss.
Realistically, you don't just show code to your boss, but there's a process for approving or rejecting
changes.
But anyway, in this simplistic world, my boss gets angry, or maybe not even angry.
She just says, You know what?
These colors suck.
We can't move forward with that.
But that's okay.
I use Git.
I have this series of checkpoints.
I can go back in time to earlier checkpoints.
So this is what it looked like at this checkpoint.
But I can go backwards too.
So from before the time I added the dark theme.
Now we're back to this light theme, and then I could even branch off.
I could start working from this point and create a new sort of fork where I can have an alternate timeline.
So this works.
Not lost.
I'm just not doing it right now.
I'm.
Working on a new version.
So I added more content if you can see that there.
So I had two rows of content.
I add more content.
Now I've picked up development at this point in time.
So I add a third row, maybe I add a new footer down there.
So we get a new check point.
If I want to add a check point then and then I could switch back to what I had earlier.
At this point, I can toggle between them.
I can use Git to say go all the way back to when I first added the nap bar or go all the way up to when
I updated the nap bar.
I made it yellow or go to add footer.
I can hop around and compare and I could present both to my boss.
They both can exist, which is the crazy part.
It helps us manage all of these different versions so I can switch back to this dark mode checkpoint.
But what's even crazier?
I can even combine these checkpoints, the work, the changes between the two.
So this dark mode had the dark colors and add footer, had all this extra content with a footer and
a third row.
So I combined them to end up with a footer and a third row of content and the dark mode colors.
So I now have a hybrid and that's exactly the sort of thing that it helps us with.
Now this is a simplified example, but imagine now I'm working on a project.
It's not just me.
There's ten people or 100 developers, lots of files, lots of versions.
How do we coordinate all those changes between all of us and combine them?
Right?
We don't all just work in silos on our own.
We need to combine that work back into some code base at some points or whatever we're working on.
We share those changes.
So it's this times hundreds and hundreds, often at a large company.
Okay, so that's the basic idea of Git and what it can help us with, just trying to visualize it for
you.
Next up, I guess totally optional.
I'm going to talk about the history of Git.