Get Started with Source Control

0:00Welcome to the content that is a bit of a crash course on source control, specifically using Git and a little bit of GitHub sprinkled in there. Look, Git is not explicitly identified on the JNCIA DevOps certification exam. However, Automation Tools is. And as you just witnessed when we went through that last skill on DevOps culture, you saw that DevOps quite literally doesn't happen without Git or source control. That is the first thing that ever happens that kicks off our entire DevOps pipeline is source control.

0:35Now, if you're gonna be writing code at all, pretty much ever, at any point in your life, you need to do it with source control. It's not a huge lift. It's not a lot extra to do things like creating commits and tracking changes and having versions of our code that we can refer back to at any time. In fact, it's a critical skill to have, especially if you are doing this for professional reasons, like you want to get into this type of work or into this type of career.

1:05You're going to need to have your own GitHub with your own open source software or your own scripts that you can demonstrate. You need to be able to show people that you can collaborate on code, and that's really the entire point of source control. It is the collaboration tool that also serves as the starting point of our DevOps pipelines. So if you're gonna have a DevOps exam or DevOps is gonna be in the name of the exam, you better have source control as part of it. You just have to.

1:35It's just the thing that you have to do if you ever get into anything related with code. So we're gonna do a quick crash course on getting started with Git and GitHub. Let's go.

0:00We're ready to get started with Git. But in order to get started with Git, you, well, have to have Git. And this is one of those things that kind of doesn't ship with default, or ship by default, with operating systems. At least not with most operating systems. I'll say there's an exception for Linux, especially Ubuntu Server. That usually does ship with Git. But if you have some form of lightweight build, or like a minimal install build of Ubuntu Server, you'll probably still have to go out and Git Git with the good old AppGit install Git. Now with Windows, there are a few different ways. You can download the installer, the standalone installer right there. Or you could use something like the WinGit tool, which I actually highly recommend here. The thing with the installer, I want you to be aware of this right now, the first time you install Git for Windows on the installer. It is a really big installation. Not that it takes up a lot of hard disk space, but it has a lot of prompts and options. It's not just like next, next, install, finish. There's going to be like a lot of next, next, next, next, next, next, next, next, next, install. Here's the kicker. Don't change any of the default options. It will install just fine if you change nothing. And if you don't understand

1:17what's going on, it's not a big deal. That's for really, really advanced, complex use cases, enterprise grade installations where they have specific teams doing specific things. That's what all those options are for. For you, the JNCIA DevOps learner, you're perfectly fine just downloading the installer and just clicking next to all of it, click install and click finish and you'll be up and running. Still, if you don't have a WinGit, I really recommend that. For Mac OS, again, it's kind of a similar boat here. The easiest way to get it is, of course, to give it a brew install. Hard to mess up brew install Git. Personally, because I do a lot of development, I actually use the Xcode command line tools. I install the Xcode command line tools and it ships with that. So when you install the Xcode command line tools, you already have Git at that point and you're up and running. Now, where do you go from here? You should be able to open up any terminal that you want. So in the Windows world, you're going to use the Windows terminal.

2:20It does ship with a Git CLI tool. Don't worry about using the Git CLI tool. You should be able to use the regular old Windows terminal. Mac OS uses a terminal and Linux basically is a terminal. So there you go. So when you have the Windows terminal, you'll type in Git hyphen lowercase V. Notice the uppercase V that I tried above doesn't work. If you do Git hyphen lowercase V and it spits out your Git version, that's how you know it's working. So where do we go from here? Well, what you need to do is a couple things. You need to have Git and you need to have an IDE.

2:56Again, I highly recommend cursor. If you can't spring for the $10 a month or $20 a month or whatever it costs, you can use VS Code. That's fine. It does mostly the same things, or at least it develops code. The difference, of course, is that with VS Code, you have to know what you're doing, whereas cursor has AI built into it and you get a lot of help. You still have to know what you're doing, but you get a lot of help getting started when you use something like cursor. So now that I have cursor and I have Git, what I'm going to do is I'm going to move into my code folder that I've created where I keep all of my code projects, and I'm going to make a new folder. I'm going to call this makedir jncia-devops, like so. So in Linux, this creates a new folder, make directory, then the name of the directory that I just created. I'll change directory into that jncia-devops folder. So I see I'm now in jncia-devops. And what I can do here, since I have cursor installed, I'm going to type cursor dot. This launches cursor with this folder already loaded. Now, the first time you type this in, it'll prompt you something like, hey, we've never run this command before, but cursor can install a helper. So you just click yes to that and you should be off to the races. When I press enter right here,

4:14watch what it does. Takes a second, thinks about it, and launches cursor. And now I'm in cursor, and if I bring up my side panel right here, you can see right there I'm in the jncia-devops folder. Now beyond this, what I'm going to do is I'm going to bring up the terminal. So if I do toggle panel right here, that button, you can see it launches the terminal down here too. So this is like having that same terminal right here, but in cursor as well. So I'll kind of minimize this so it doesn't take up too much space. I'll also kind of see if I can adjust this font a little bit. I can't really zoom without blowing up the entire selection here. What I could probably do is hide the chats or kind of close it like this if I need to, and then I could zoom in or I can just use this regular terminal right here. So here's what we need to do to start a git project so that it starts tracking changes in my environment. I'm going to type the command git init. That's initialize a git repository in this folder that I'm currently in. So I'll press enter right there. It initialized an empty git repository in this folder right there. You see

5:30jncia devops called .git. Remember if folders begin with a dot, it's hidden. For instance, if I type ls right here, it shows me I have no contents of this folder. But if I type ls hyphen a, as in show me all contents, even hidden contents, now I see the git folder is in there. Inside this git folder, we actually have a lot of stuff. You don't really need to know anything that goes on inside this git folder for the basics of git. You should just know this is where all the git magic happens inside this git folder. This is where it keeps track of the current version of the code and also all of the old versions of the code from there as well. So at this point, you should have installed git, you should have launched your IDE in a folder, and you should have initialized a repository inside that folder. When I flip back here, notice it doesn't show me that hidden folder right here, and that's okay because where git is actually managed in the cursor application as well as VS Code is right here with this little symbol like that. That's the source control folder. So when I click on this, this is where it'll actually start tracking all the changes and we manage git from here. So you could kind of think about it like

6:48the .git folder is not present in the JNCIA DevOps browser right here, but it is actually connected in through this source control tab right here, and we're going to start using this more in the next few videos.

0:00So at this point, we have Git. We have cursor loaded with Git. You know, it's got a folder that it's attached to, but Git in source control isn't doing anything. One of the first things we have to do is we have to create new files and then tell Git we're ready to start tracking changes on these files. To do that, it is a two-step process. I'm going to walk you through the step right now. The first thing I'm going to do is I'm going to create a README file.

0:33So to create an empty file on any Linux-based operating system, we use touch and then we say the name of the file. Traditionally in repositories, the file is README, all caps, .md. That is a markdown file. So I press enter right here and this creates the file. You can flip over to cursor right here and back into the folder section. You see in cursor, we see the README file, boop. And importantly, you see it's green and it has this U right here.

1:07U means untracked. It's not doing anything with this file right now. So I can do anything I want to with this file and source control doesn't care because we haven't told it you need to start tracking changes to this file. So what I'm going to do is I'm going to put a header in here. We do that with a basically a pound or a hashtag and we'll just write header goes here. Then I will do command S to save this file.

1:37So that file has a change inside of it and now I'm ready for Git to start tracking the changes. So what do we do to make this happen? This is a two-step process. The first step is staging. Stage, you got to spell staging correctly. And the second step is committing. So the idea with this, with staging is we pick the individual files and say we're done working on those files.

2:08So in this case, I have my README file, right? README.md. And I can say I'm done working on this particular file. So I will stage it to be ready to be committed. So to do that, watch this. We can first say git status and it shows you right here we have untracked files, README.md. There's no commits yet. And importantly, right here it says use git add to include this file in what will be committed.

2:45That is meaning we are going to stage this file as it exists right now. So I will say git add README.md. So what we're saying at this point is I'm done working on the README file. I still haven't created a commit or a version of the code. The idea here is what if I have other files that I want to work on right now? What if I want to create a new file?

3:15And I want that new file to be included in the commit. I can do touch and we'll call this hello-world.py. If I do ls, I see I now have two files. You can also check in cursor. I've got two files right here. And if I do git status, I see, okay, this file's ready to be committed. This one is currently being untracked. So what I need to do is I need to start tracking hello-world or I can create a commit that just includes the README.

3:51So let's create a commit that just includes the README from the CLI and then I'll show you what staging and committing looks like from within cursor using the Python file. So now that I've got this file staged and we're saying, okay, we're done working on that file and now I'm ready to make a commit. I'm ready to say, okay, this is the first version of my project. I'll say git commit right here at the bottom. I'll say hyphen m because we're going to put a message or a memo that describes what this commit does.

4:25That's really important. I'll say open quotes and say, this is first commit semicolon committing README.md. I'll close the quotes right there. And this is the full command, git commit with a message or a memo. This is the first commit committing README.md. A descriptive commit message is really, really important. Let me say this again.

4:56A descriptive commit message is really, really important. You will use this. You will go back and look at these commit messages. I promise you will. I'll press enter right here. And in my case, in my local environment, it wants to use SSH keys to sign my commit messages. I have configured this for a different project in different reasons. You will not get this prompt, okay? I'm going to just go ahead and use my fingerprint to sign it and it's created the commit message.

5:28I will say this, bringing up the git documentation. It is very common to receive an error saying you haven't set up your name or email yet. And that's true. With the first time you run git, whenever you create a commit, you sign it with your contact information, your name and an email address that you can get contacted with. So when I just created that commit, I've already set up a username and an email address to attach to all of my commit messages.

6:02Every commit message I ever put in there is also going to include in the metadata, my username and email address. So if you receive an error saying you haven't set up your username or email address, type these commands right now. Git config global user.name and put whatever name you want there. You can put John Doe in there and it'll all still work. You can say you're Matt Damon and it'll still work. And then the same thing goes with email addresses.

6:33You can put your email address in there if you want to be contacted for doing some commit. You can also put johndoe at example.com. If you don't want to be contacted for some commit, you can remain anonymous for whatever reason you want to do. Git just has to have something there in order to create the commit. It has to have that. So run these two commands, putting in whatever name or whatever email you want, and then reattempt the commit again and it will work this time.

7:04Cool? Good. Now, in my case, when I ran this commit message, something really important happened. It created a commit. It created the first version of this code. And importantly, it created a commit hash. This is a hash that hashes all of the code inside of your project. And it is a unique and quick way to identify your commit. We're going to talk more about this in an upcoming video, but just know that this is what the output looks like.

7:35And the important takeaway right here is the commit hash along with the commit message that goes inside of it. Now, when I flip back to cursor here for a second, let me go to cursor, we now see the readme.md file is white and there's no message here. That means we are at the latest version of this file. There's no new changes. If I change it now and I say blah, blah, blah, blah, like this, and then save the file, now we have a changed file.

8:06So after just a second, the left-hand side updates and we now see it's kind of brown with an M. The M meaning it has been modified since the last time we've worked with it. I'll show you how to do some cool stuff with this in a second. But now what I'm going to do is I'm going to put something in my Python file, then stage that and commit it. So I'll say print, and then I'll tab to auto-complete. You saw that prompt there for a second. Let's try that again. I'll show you what happens. If I type print, see this subtext, this prompt right here?

8:41I haven't typed parentheses, hello world. This is the AI that is coming from cursor. Cursor is auto-suggesting some code that is typically run whenever we start typing. And it says like, we think you're going to type hello world, so you could just hit tab to auto-complete the code. It guesses what you're going to type next, which is really cool. I'll do command S to save this. Now, if I wanted to stage and commit this via the CLI, we know I would do git add hello world.py, and then a git commit with a message.

9:14But if I want to do this from cursor, I'm going to go into the source control tab right here, and I see right here's the changes. I see hello world.py, and I have some buttons that come right after this. To stage the changes, basically like clicking git add, all I have to do is click the plus sign. Now I see this file is staged for committing, which is really cool, right? When I want to make a commit, I can type in my commit message and say, added hello world.py right here in the text bar, and click the commit button.

9:53I'll sign it again, in my case, because I've set it up to do that, and you won't have to deal with it. Now I have two commits, and we see the commit tree going up in this direction. Here's the first commit, which I can click on, and it shows me what happened in the first commit. Here's the second commit, which I can click on, and it shows me what happened in this commit. I'll close out of this for a second and show you some other cool things, like I promised. Right here, we still see I have unstaged and uncommitted changes to readme.md.

10:31What were those changes, I wonder? If I click on this, it shows you a before and an after view of what has happened. This is what the last commit holds. This is what the current file on the hard disk holds, and we see a little plus here to show that I added this content right here. Well, that content is nonsense, and I don't want it in this particular commit. So what I can do is I can discard these changes, rolling back to the previous commit, by hitting the little undo error.

11:05If I give that a click, it says we're going to undo all these changes and roll back to what you had in the previous commit. When I click discard file, there it goes. So now when I look in my readme.md file, there it is as it currently stands. So I can say added some legit text, command S to save that. I see the change, I stage the change, and I say updated readme.

11:36I commit the change, and now down here, I have my third commit showing in the commit tree. So this is staging and committing code that we can now see how it has changed from one version to the next. The big takeaway here is we stage one file at a time, typically, when we're done working with that file. And once we're done working with all the files we want to change, then we make our commit.

0:00So in that last video, you might be thinking to yourself, the secret sauce is really down here, where we start tracking the changes of each one of these commits. This is known as the Git log. And what Cursor has done here, and VS Code for that matter, because this is really a VS Code fork, is we have visualized the Git log. So I'm actually first going to talk about the Git log, or at least from the Cursor perspective before we move on.

0:32Let's make another change. I'm going to come back in here, and I'm going to update one of the given lines. We're going to change header goes here to now something like beginning source control lessons. That's a good header right there. So I've changed this given line, I've modified it. I'm going to come in here, I'll stage it and I'll change updated, read me header, nice and descriptive. I know what's going on, and I'm not worried about publishing the branch right now.

1:02Right now I see I've got a new commit message down here. So when I see the updated read me right here, I can click on it and I can see what's changed. Let's hover over this for a second and take a look at what's going on. It's kind of hard to see, so I apologize for that. If I click, you can kind of zoom in and see. First of all, we can see the date and time that this commit was made. We see the message updated read me header. We see one file was changed and then this is interesting.

1:33It shows one insertion and one deletion. Anytime you update an existing line of code, Git sees that as a delete and recreate, delete and insert. So you're not going to see a change. You're going to see delete and insert. In fact, up here in the comparison, we're going to talk about this more in the next video, we see this as a minus and a red box. So we visualize this as a deletion. And then we see the same line, line one, as a plus and then a green box as new code.

2:10So Git will always see an updated line as a delete and reinsert. That's a really important thing to understand. Back down here again, we see I'm currently on the main branch and then this is that Git hash. More on that in just a second. Now, just for fun, to make this interesting, I'm going to create another new file. We'll call this tester.py. And I'll put just some, any code in here that says print. We'll say this is a test.

2:44Auto-complete tab, command S save, stage and commit with created new test. tester.py file commit. And of course I see the tree update down here. So I've got a new commit visualized here. So we have an idea at least what the Git log is going to show us from within cursor and what clicking on each one of these commits kind of tells you at a very high level. Let's see what we can do from the CLI.

3:16From the CLI, first of all, if I give this a git status, I see my working tree is clean, meaning I don't have any files with changed updates. We're up to date on everything. So now what I can do is I can type git log, and this gives me kind of a text output of that visualization that we were seeing in cursor. Why do I like this more? Well, it's a little more descriptive and it's certainly a lot more space on the screen than this tiny little box down here. Now this takes up the whole screen because I'm on the CLI.

3:49So what do we see? Starting from the bottom, we see the commit message. We see the date and time that it was created, including the time zone. I'm at minus six right now, that's central time US. We see the author. Ah, remember I said you need that username and email address. Imagine if you were contributing code, you were working on open source code with hundreds of users from all over the world. When you run git log, you'll see all of their commits and their contact info.

4:22All of a sudden, the feeling of maybe staying anonymous for a little bit seems like a good idea because you don't want anybody to just email blast you and say, you did this wrong or something like that. You know what I mean? Like you could just work on code and contribute small things without putting yourself out there if that's what you're worried about. The next thing is, is there's the commit hash itself. Again, really important to know your commit hash. So we see all of these right here for each one of these commits. The one at the very top has a little extra information, doesn't it?

4:54We see this head pointed to main. What is this all about? Head is the commit that you are currently on. You could think about head as the commit that your code currently shows if you were in cursor or what is, where am I on the disk right now? So if we were mapping out these commits, let's just call this commit one, two, three, four, and five. It would look like we started with commit one, we went to commit two, we went to commit three, we went to commit four, we went to commit five, and then just an open line.

5:36This open line is known as the head. You are here. And importantly, this is all happening on the main branch. Why do we care about this? Because if we were working on something like a bug fix for a second, maybe the main branch would have gone from commit one to commit two to commit three, and then you realize there's a bug. So you clone the repository and start a new branch right here for the bug fix.

6:09Maybe the name of that branch is called bug fix, and you'll have commits from here. And this will be your commit four, your commit five, and then maybe this is your current head right here. So instead, your tree might look like this. And that's how you know, oh, my head is currently pointed towards bug fix, and this is the commit that I'm currently on.

6:40So when we're done, when we're done with all this code, maybe we make some changes and some edits, what we'll eventually do is migrate via a formalized process called a pull request that's way beyond the point of this skill or this entire course. There is a formal process for merging that code down here and updating the code where this becomes the new head with our bug fix code implemented in it. The point is, is we see, okay, this is where my code currently is, and this is the branch that I'm currently working on.

7:13That's why head and main are here. Now there's a quicker way that we can look at this. We can say get log hyphen hyphen one line, all one word. When I press enter here, now it shows me an abridged cleaner output that more mimics what you're seeing in cursor. It shows you enough of the commit hash to make it unique. It shows you what the message is. And in this case, it shows you where the head and the branches, but it doesn't tell you anything like the full commit message.

7:46It doesn't show you the date and it doesn't show you the author. So let's now say, I'm really interested in what the code looked like right here when I was on this commit. I can run get checkout. I'll highlight this commit hash. Even the abridged will work. I'll paste it in right here and I'll press enter. Oh, you are now, your code has now been changed at least temporarily to what the code looked like at this commit hash.

8:20Look, if I flip back into cursor even, ah, my tester file is gone, isn't it? And if I look at the readme, we've now reverted the text at the top to header goes here. Do you see why git is now powerful? We can go back in time, changing what the file looked like. The file on disk, the readme file and the Python file on disk is now what it looked like when this commit hash was created.

8:50Kind of crazy, right? This is just kind of showing you where these commit hashes come into play. Now that I'm ready to go back to the future, if you will, go back to where we were, I can do git checkout back to this hash and now I'm in a good state. If I say git status, we see I'm in this hash right here and I'm on main, just like that. You can also say git checkout main like this.

9:22And now my branch is on the main branch. If I say git status like so, now I am on the latest commit on the main branch. If I look back here in source control, it tells me exactly where I am right here on the main branch with my tester.py file right here on the disk. So this is the power of git log, seeing what we've done. And hopefully it also kind of illustrates the importance of having really good commit descriptions.

9:54So you know what each commit was doing.

0:00Now we're going to have some real fun and that's leveraging GitHub to track our code and collaborate on code. This again is going to be a very basic intro just to get you familiar with where GitHub comes into play in the whole world of Git. Basically the idea is we're going to publish our code onto somebody else's server, onto a GitHub server, where it can either live privately where only I can access it and other people I invite to collaborate, or it can live publicly where the whole world can access it and they can collaborate as well.

0:35Start by going to GitHub, if I can type right here, github.com and if you don't have a GitHub account, sign up for free. Go through that process right now, signing up for GitHub and sign up for free. I've already got an account so I'm going to sign in. I am now signed into GitHub and what's really cool about GitHub is you can always remember the URLs are pretty easy. Whenever you're trying to access your own repo or anybody else's repo, it is github.com forward slash, then their username, then another forward slash, and then the name of the repository. So for instance if I'm trying to get to any of my repositories, I can go to github.com forward slash data knots and there's my profile as well as a lot of my repositories. If I were to go into the code samples repository, you know the URL is going to be github.com slash data knocks slash code samples. That's the layout for all of these repositories. Now this is an open source one, meaning it is a public repository that anybody can access. What I want to do for the JNCIA DevOps is create my own repository on GitHub and then have cursor synchronize anything I do locally with GitHub. So what we have to do to do

1:55this is a few things. Let's go back to my profile, go to your profile, and we'll create a new repository. You can look at this plus button right here, create new, and we'll do new repository. I'll call this repository JNCIA hyphen DevOps like so and since I haven't created this already, we can start working on it. You can put a description in here if you want and then importantly this is where you choose visibility. Is this going to be public for the world to see or is this only going to be allowed by you? I'm not worrying about adding anything else at this time. I'm going to leave it alone and I'll create this empty repository.

2:38I already have an existing repository and what I want to do is I want to get the state of the current code up into it. It gives you the CLI commands to run. We're going to use the git remote add origin. Basically saying we are using, there is a remote repository and we want it to originate from this URL. Don't worry, our local code is going to get pushed up there first. We're going to say the branch that we're working on is main and we're pushing up to our origin which is this URL from our local main branch. I'll copy this code right here, copy this, jump over here to my URL and I'll paste it in. Press enter a few times and now it's done. Check this out. If I go back to GitHub, I can give this a refresh.

3:31What do I see but my code including the formatted markdown file. Pretty cool, right? So now what we have the ability to do, watch this, I'm going to show you importantly how this workflow works. You can now think about how this is. We now have on the internet our central server that has our main branch and on my local computer down here, I also have a copy or a clone of that main branch. So what I can do on my local computer is I can edit my code, make new commits and then when I'm done, synchronize those back up to the GitHub repository.

4:19So I'll jump back into cursor and I'll say let's create a new file and we'll call this runner.py. I'll click on runner.py and I'll say print. This is a runner, it's fine and I'll create a stage and commit and we'll say added runner.py. We'll commit this and notice right here, now it shows me that I can sync changes and interestingly the Git log changes too.

4:53The purplish pinkish color that you see right here are commits that are synchronized with what exists in the origin. You see origin right there. So these commits all exist in GitHub. The blue ones do not. The blue ones exist locally on my machine. We can even add some more stuff to the header. We can say adding new content. We are testing, testing, spell testing correctly, GitHub, like so. Command S to save it so it's written to the disk. That way GitHub sees that changes have been made to these files or excuse me, Git sees that changes have been made to these files. We'll stage this and say updated readme with new GitHub content and make another commit.

5:48Notice again the commit exists locally, does not exist on the origin. One more change. Let's go in the tester and just make one new line here and say, you know, print and we'll say this is a second test. I'm fine with that. We'll stage it and say added second test to tester and commit it. So now I've got three new commits. The commit hashes, again really important. If I say Git log, we see now, oh wait a minute, this is where the origin is. This is the last commit on the origins main branch.

6:28We've got three new commits. We see where my local header is on my local main branch and I've got three commits, 070FF, 37D74, B6CC4 that don't exist in GitHub. If I refresh this, you can see the last commit I have is 98D1D02 from 24 minutes ago. That's down here. So it's missing these three commits right up here. So what do I need to do? I need to push them up into the GitHub origin. You can click the sync changes button to do that. That will do two things. It will push all of my local changes up into GitHub while pulling any new changes from GitHub down into my computer.

7:23If I just want to do only pushing my local changes up into GitHub, we can click the dot, dot, dot right here and click push. That takes about one second and now all of my dots right here look blue and we see the origin and main are kind of in sync right here. If I flip back to GitHub, boop, and refresh, now I have commit B6CC4 from one minute ago issued right here. Notice on GitHub, we can also click the eight commits button right here and we see all the commits as they exist right here. You can click on any one of these commits and see what code was changed. Seeing the diff, as we call it, the get diff visualized right here in this. Pretty cool, right? This is also a really important talking factor. If you publish code to GitHub with a secret, a password, anything that needs to be kept protected, if you publish it into GitHub, deleting that line of code and publishing a new commit does not make it go away. That old commit and all that old code

8:40still exists publicly. It is really, really, really, really, really important that you sanitize or cleanse all of your code of secrets whenever you can for security reasons before you make a commit and especially before you publish it or push your code up into GitHub. So now we've gotten started working with GitHub, a way that you can track the versions of your code and even publish them in such a way. Why does this matter to you, the learner of a JNCIA exam, interviews, and resume? I don't know which direction the accents go. Sorry. But the idea here is now you can demonstrate that you make code and track changes and publish code using Git, source control, and GitHub. This is a resume builder. Very, very critical to understand that this is a powerful tool for your career. All right. Now we've covered the very, very, very fundamental basics of source control. If you want to dig deep into learning how branches

9:59and pull requests and merging and conflict handling and really reading a Git diff, if you want to dig deep, I really recommend a course that we have here. That is the Linux Professional Institute Certification Exam for DevOps Tools Engineer. There is a lot of content on how Git from the basics to advanced works and then how collaboration happens with GitHub. Highly recommend, highly recommend, check out the LPI DevOps Tools Engineer course here at CBT Nuggets. I hope this has been informative for you and I'd like to thank you for viewing.

0:00Let's review what we've learned about using Git and source control, paying close attention to some of those Git CLI commands. You create a new folder for a coding project and want Git to begin tracking changes inside of it. What command should you run first? Well, it's right here at the top, init. We have to initialize that repo before we can stage and commit any of the code changes or begin tracking any of those files. It begins with Git init, which is really going to create that .git subfolder that's hidden inside of the root of our project.

0:37You edited app.py and want to prepare it to be included in the next commit, but you're not ready to save the snapshot yet. So we've got, we're done with one file. We're not ready to count this as a new version of the whole project. What command should we use? Git checkout, Git add, Git log, or Git status. Right here, we're talking about Git add. We are adding this file to the queue of files that are about to be committed. So we're done working with it.

1:10There's probably more files that we need to work on. So we staged the files that we're done with, continue our work, and then commit them all when we're done. You discover that your project was working perfectly two commits ago. You want to temporarily view the project exactly as it existed at that point in time. What command should you use? Git status, Git checkout with the commit hash, Git commit with the message revert, or Git add dot, which is Git add everything.

1:43Git checkout with a commit hash. Specifically, we're going to run Git log, probably with the one line option, and find out what that commit hash is. Then we'll run the Git checkout with that commit hash to move the head back in time to that point. We'll then look at what that code looked like and compare what was going on, why it worked so well at that point in time. So this has been refreshing what we learned about Git and source control, the very, very basics.