00:00:00 Let's add some files and track changes.

00:00:02 I'll create a new file called hello.js.

00:00:06 And you can see how smart WebStorm is.

00:00:08 It automatically asks me whether I want to add it to Git.

00:00:11 But for now, I'll cancel that because I want to explain everything manually.

00:00:15 Let's make it simply run a console.log that prints hello Git.

00:00:20 Alongside this file, let's create another new file and I'll call it readme.md.

00:00:26 In here, we can do something similar and say hello Git.

00:00:31 And now, run git status.

00:00:34 Git will tell you that you're currently on the main branch, that there are no commits yet, and that there are two untracked files,

00:00:40 one of which is a markdown document.

00:00:43 So, to track it, use git add readme.md.

00:00:49 After adding a file, we need to commit it.

00:00:51 Committing in Git is like taking a snapshot of your project at a certain point.

00:00:55 Think of it as creating a whole new copy of your folder and telling Git to remember when you did it, at what time.

00:01:02 So, in the future, if anything happens, you'll time travel to this folder with the commit name you specified to Git and see what you had in there.

00:01:11 It's essential to commit your changes regularly.

00:01:13 Regular commits help you keep track of your progress and make it easier to revert to previous versions if you break something.

00:01:20 You can commit by running git commit dash m, which stands for message.

00:01:25 And then in single quoted strings, you can add that message.

00:01:29 For example, add readme.md file.

00:01:33 There we go!

00:01:34 Congrats!

00:01:35 You just created a checkpoint in your project's history.

00:01:38 Now, let's try running git status again to see what it shows.

00:01:42 As you can notice, that other file, hello.js, is still there.

00:01:46 It's not tracked.

00:01:48 We asked git to track only the readme file.

00:01:51 To track this file or other files that you may create, we'll have to run a similar command.

00:01:56 It'd be too much work to commit each file individually.

00:01:59 Thankfully, we have a command that commits all the files we've created or modified that Git is not tracking yet.

00:02:06 To see this in action, let's create another file.

00:02:09 Test.js.

00:02:11 And let's add a simple console log that simply console logs a string of test.

00:02:16 Now, to track both files and commit them in a single commit action, we can do that by running git add dot.

00:02:23 The dot after git add tells Git to add all files created, modified, or deleted to the Git tracking.

00:02:30 Next, as usual, we can specify the commit name for this tracked version by using git commit –m add hello and test files.

00:02:42 There we go.

00:02:43 So now we can see that all of these files are tracked.

00:02:46 And since I'm using WebStorm, it also has a hidden .idea folder, so it added it to tracking as well, which I'm okay with.

00:02:53 Well done.

00:02:54 Now to see the history of all commits we've created, we can use a new command, git log.

00:03:00 And there we have it, our git history.

00:03:02 It contains a commit ID or a hash automatically created by git, the author we specified when using git config, a timestamp,

00:03:11 and the commit message we provided.

00:03:12 Thank you.

00:03:13 Great, but how do we switch to an older commit and restore it?

00:03:17 Let's say the commit add hello and test files introduces some buggy code, and we want to restore our project to a previous version without these files.

00:03:25 Our brain would immediately suggest deleting those files entirely or clearing up their code.

00:03:31 And if you do that, you'll most likely break your production because other files depend on those files.

00:03:36 So instead of deleting them manually to restore to the first version where we had only committed the readme file, we can use a new command.

00:03:44 First, you have to copy the commit hash.

00:03:46 Yours is going to be different from mine, so make sure to copy yours.

00:03:50 I'll get this one first that says add readme.md file, and I'll press copy.

00:03:55 Then you have to exit this Git log by pressing the Q letter on the keyboard, and then you can use the command git checkout,

00:04:02 and then you can provide a hash of a specific commit or a branch you want to check out too.

00:04:07 Now press enter.

00:04:09 Okay, something happened.

00:04:11 First of all, our two files are gone.

00:04:14 Detached head, experimental changes, what's happening?

00:04:17 Well, in Git, there is a concept of a head, which refers to the pointer pointing to the latest commit you've created.

00:04:24 When we created our second commit, our head shifted from readme commit to the latest add hello and test files commit.

00:04:31 But when we ran git checkout command, we moved the head to the previous, older commit.

00:04:37 That's why we got this detached head warning.

00:04:39 It's a state where the head pointer no longer points to the latest branch commit.

00:04:44 And the rest of this message tells you that you can create a new branch off of this commit.

00:04:49 But don't worry, your files are still somewhere.

00:04:52 When you use a git checkout command, you're simply viewing the repository state as it was at the time of a specific commit.

00:04:59 Like right now, we're viewing a snapshot of your code base at a previous moment in time when we only had a readme.md file.

00:05:07 The beauty of this is that all the logs and files, whether created or modified, remain untouched.

00:05:13 The git checkout command won't delete any logs or history, so you can safely explore past states without worry.

00:05:20 But what if you actually want to discard changes made after that commit?

00:05:24 Maybe you want to quickly roll back to a stable state after an issue hits production, tidy up messy commits to look more professional,

00:05:31 or undo a bad push you regret making.

00:05:33 Perhaps you've been experimenting with a refactor that didn't pan out, or you need to recover from a messy merge conflict.

00:05:40 Thankfully, Git provides a few commands that'll help you in these scenarios.

00:05:44 and I'll teach you how all of that works very soon.

00:05:47 So just keep watching and we'll dive into these more advanced commands that are really gonna help you, well, fix a broken production.

00:05:54 Now, to go back to our current state, which is often called the head state, you simply have to run git checkout.

00:06:02 And there we go.

00:06:03 Previous head position was at the hash of this checkout, and now you switch the branch to main.

00:06:08 You can see the same thing happen right here on the bottom right or the top left, depending where your branching is.

00:06:14 And if you made any changes while in the detached head state and you want to discard them, you can do the same thing, get checkout,

00:06:21 dash F, that means force, and then get back to main.

00:06:24 In this case, we're good, we're already on main.

00:06:27 And that's it.

00:06:28 You already know more about Git than most developers do.

00:06:32 Of course, we'll dive deeper into advanced use cases and tips and tricks soon, but now let's talk about GitHub and how it differs from Git.