Get Started with Source Control

0:00Welcome to the content that is a bit of a crash course

0:03on source control, specifically using Git

0:06and a little bit of GitHub sprinkled in there.

0:09Look, Git is not explicitly identified

0:12on the JNCIA DevOps certification exam.

0:14However, Automation Tools is.

0:18And as you just witnessed

0:19when we went through that last skill on DevOps culture,

0:22you saw that DevOps quite literally doesn't happen

0:26without Git or source control.

0:28That is the first thing that ever happens

0:31that kicks off our entire DevOps pipeline is source control.

0:35Now, if you're gonna be writing code at all,

0:37pretty much ever, at any point in your life,

0:40you need to do it with source control.

0:43It's not a huge lift.

0:44It's not a lot extra to do things

0:47like creating commits and tracking changes

0:50and having versions of our code

0:51that we can refer back to at any time.

0:54In fact, it's a critical skill to have,

0:56especially if you are doing this for professional reasons,

1:01like you want to get into this type of work

1:03or into this type of career.

1:05You're going to need to have your own GitHub

1:08with your own open source software

1:10or your own scripts that you can demonstrate.

1:13You need to be able to show people

1:14that you can collaborate on code,

1:17and that's really the entire point of source control.

1:20It is the collaboration tool that also serves

1:24as the starting point of our DevOps pipelines.

1:26So if you're gonna have a DevOps exam

1:29or DevOps is gonna be in the name of the exam,

1:31you better have source control as part of it.

1:34You just have to.

1:35It's just the thing that you have to do

1:38if you ever get into anything related with code.

1:41So we're gonna do a quick crash course

1:43on getting started with Git and GitHub.

1:46Let's go.

0:00We're ready to get started with Git. But in order to get started with Git, you, well,

0:05have to have Git. And this is one of those things that kind of doesn't ship with default,

0:10or ship by default, with operating systems. At least not with most operating systems.

0:16I'll say there's an exception for Linux, especially Ubuntu Server. That usually does

0:21ship with Git. But if you have some form of lightweight build, or like a minimal install

0:26build of Ubuntu Server, you'll probably still have to go out and Git Git with the good old

0:31AppGit install Git. Now with Windows, there are a few different ways. You can download the

0:37installer, the standalone installer right there. Or you could use something like the WinGit tool,

0:42which I actually highly recommend here. The thing with the installer, I want you to be aware of this

0:47right now, the first time you install Git for Windows on the installer. It is a really big

0:53installation. Not that it takes up a lot of hard disk space, but it has a lot of prompts and

0:59options. It's not just like next, next, install, finish. There's going to be like a lot of next,

1:05next, next, next, next, next, next, next, next, install. Here's the kicker. Don't change any of

1:11the 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,

1:24enterprise grade installations where they have specific teams doing specific things.

1:28That's what all those options are for. For you, the JNCIA DevOps learner, you're perfectly fine

1:35just downloading the installer and just clicking next to all of it, click install and click finish

1:39and you'll be up and running. Still, if you don't have a WinGit, I really recommend that.

1:43For Mac OS, again, it's kind of a similar boat here. The easiest way to get it is, of course,

1:49to give it a brew install. Hard to mess up brew install Git. Personally, because I do a lot of

1:55development, I actually use the Xcode command line tools. I install the Xcode command line tools and

2:01it ships with that. So when you install the Xcode command line tools, you already have Git at that

2:08point and you're up and running. Now, where do you go from here? You should be able to open up

2:13any 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

2:26to use the regular old Windows terminal. Mac OS uses a terminal and Linux basically is a terminal.

2:32So there you go. So when you have the Windows terminal, you'll type in Git hyphen lowercase

2:38V. Notice the uppercase V that I tried above doesn't work. If you do Git hyphen lowercase V

2:43and it spits out your Git version, that's how you know it's working. So where do we go from here?

2:50Well, 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

3:01whatever it costs, you can use VS Code. That's fine. It does mostly the same things, or at least

3:07it develops code. The difference, of course, is that with VS Code, you have to know what you're

3:11doing, whereas cursor has AI built into it and you get a lot of help. You still have to know what

3:16you're doing, but you get a lot of help getting started when you use something like cursor.

3:22So now that I have cursor and I have Git, what I'm going to do is I'm going to move into my

3:27code folder that I've created where I keep all of my code projects, and I'm going to make a new

3:31folder. I'm going to call this makedir jncia-devops, like so. So in Linux, this creates a new folder,

3:39make directory, then the name of the directory that I just created. I'll change directory into

3:44that jncia-devops folder. So I see I'm now in jncia-devops. And what I can do here,

3:50since I have cursor installed, I'm going to type cursor dot. This launches cursor

3:58with this folder already loaded. Now, the first time you type this in, it'll prompt you

4:03something like, hey, we've never run this command before, but cursor can install a helper. So you

4:09just 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,

4:23and if I bring up my side panel right here, you can see right there I'm in the jncia-devops

4:30folder. Now beyond this, what I'm going to do is I'm going to bring up the terminal.

4:33So if I do toggle panel right here, that button, you can see it launches the terminal down here

4:39too. So this is like having that same terminal right here, but in cursor as well. So I'll kind

4:47of minimize this so it doesn't take up too much space. I'll also kind of see if I can adjust this

4:53font a little bit. I can't really zoom without blowing up the entire selection here. What I

4:59could probably do is hide the chats or kind of close it like this if I need to, and then I could

5:04zoom in or I can just use this regular terminal right here. So here's what we need to do to start

5:10a git project so that it starts tracking changes in my environment. I'm going to type the command

5:17git init. That's initialize a git repository in this folder that I'm currently in. So I'll press

5:24enter 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,

5:38if I type ls right here, it shows me I have no contents of this folder. But if I type ls hyphen

5:43a, as in show me all contents, even hidden contents, now I see the git folder is in there.

5:50Inside this git folder, we actually have a lot of stuff. You don't really need to know anything

5:56that goes on inside this git folder for the basics of git. You should just know this is where

6:02all the git magic happens inside this git folder. This is where it keeps track of the current

6:07version of the code and also all of the old versions of the code from there as well. So at

6:13this point, you should have installed git, you should have launched your IDE in a folder, and

6:19you should have initialized a repository inside that folder. When I flip back here, notice it

6:24doesn't show me that hidden folder right here, and that's okay because where git is actually

6:30managed in the cursor application as well as VS Code is right here with this little symbol like

6:37that. That's the source control folder. So when I click on this, this is where it'll actually start

6:42tracking 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,

6:54but it is actually connected in through this source control tab right here,

6:59and we're going to start using this more in the next few videos.

0:00So at this point, we have Git.

0:02We have cursor loaded with Git.

0:06You know, it's got a folder that it's attached to,

0:08but Git in source control isn't doing anything.

0:12One of the first things we have to do

0:15is we have to create new files and then tell Git

0:19we're ready to start tracking changes on these files.

0:24To do that, it is a two-step process.

0:27I'm going to walk you through the step right now.

0:30The first thing I'm going to do

0:31is I'm going to create a README file.

0:33So to create an empty file

0:34on any Linux-based operating system,

0:37we use touch and then we say the name of the file.

0:40Traditionally in repositories,

0:43the file is README, all caps, .md.

0:46That is a markdown file.

0:48So I press enter right here and this creates the file.

0:51You can flip over to cursor right here

0:56and back into the folder section.

0:57You see in cursor, we see the README file, boop.

1:02And importantly, you see it's green

1:04and it has this U right here.

1:07U means untracked.

1:09It's not doing anything with this file right now.

1:12So I can do anything I want to with this file

1:15and source control doesn't care

1:17because we haven't told it

1:18you need to start tracking changes to this file.

1:22So what I'm going to do is I'm going to put a header in here.

1:26We do that with a basically a pound or a hashtag

1:29and we'll just write header goes here.

1:33Then I will do command S to save this file.

1:37So that file has a change inside of it

1:39and now I'm ready for Git to start tracking the changes.

1:42So what do we do to make this happen?

1:44This is a two-step process.

1:47The first step is staging.

1:50Stage, you got to spell staging correctly.

1:54And the second step is committing.

1:59So the idea with this, with staging

2:02is we pick the individual files

2:04and say we're done working on those files.

2:08So in this case, I have my README file, right?

2:13README.md.

2:16And I can say I'm done working on this particular file.

2:20So I will stage it to be ready to be committed.

2:24So to do that, watch this.

2:26We can first say git status and it shows you right here

2:31we have untracked files, README.md.

2:36There's no commits yet.

2:38And importantly, right here it says use git add

2:41to include this file in what will be committed.

2:45That is meaning we are going to stage this file

2:49as it exists right now.

2:51So I will say git add README.md.

2:56So what we're saying at this point

2:58is I'm done working on the README file.

3:02I still haven't created a commit or a version of the code.

3:07The idea here is what if I have other files

3:10that I want to work on right now?

3:12What if I want to create a new file?

3:15And I want that new file to be included in the commit.

3:18I can do touch and we'll call this hello-world.py.

3:23If I do ls, I see I now have two files.

3:26You can also check in cursor.

3:27I've got two files right here.

3:30And if I do git status, I see, okay,

3:34this file's ready to be committed.

3:37This one is currently being untracked.

3:40So what I need to do is I need to start tracking hello-world

3:46or I can create a commit that just includes the README.

3:51So let's create a commit that just includes the README

3:54from the CLI and then I'll show you

3:56what staging and committing looks like

3:59from within cursor using the Python file.

4:02So now that I've got this file staged

4:05and we're saying, okay, we're done working on that file

4:07and now I'm ready to make a commit.

4:09I'm ready to say, okay,

4:10this is the first version of my project.

4:12I'll say git commit right here at the bottom.

4:15I'll say hyphen m because we're going to put a message

4:22or a memo that describes what this commit does.

4:25That's really important.

4:27I'll say open quotes and say,

4:30this is first commit semicolon committing README.md.

4:38I'll close the quotes right there.

4:41And this is the full command,

4:43git commit with a message or a memo.

4:46This is the first commit committing README.md.

4:50A descriptive commit message is really, really important.

4:55Let me say this again.

4:56A descriptive commit message is really, really important.

5:01You will use this.

5:03You will go back and look at these commit messages.

5:06I promise you will.

5:08I'll press enter right here.

5:10And in my case, in my local environment,

5:14it wants to use SSH keys to sign my commit messages.

5:17I have configured this for a different project

5:20in different reasons.

5:21You will not get this prompt, okay?

5:23I'm going to just go ahead and use my fingerprint

5:25to sign it and it's created the commit message.

5:28I will say this, bringing up the git documentation.

5:32It is very common to receive an error saying

5:34you haven't set up your name or email yet.

5:37And that's true.

5:39With the first time you run git,

5:41whenever you create a commit,

5:44you sign it with your contact information,

5:48your name and an email address

5:51that you can get contacted with.

5:54So when I just created that commit,

5:57I've already set up a username and an email address

6:00to attach to all of my commit messages.

6:02Every commit message I ever put in there

6:04is also going to include in the metadata,

6:07my username and email address.

6:10So if you receive an error saying

6:12you haven't set up your username or email address,

6:14type these commands right now.

6:17Git config global user.name

6:20and put whatever name you want there.

6:23You can put John Doe in there and it'll all still work.

6:26You can say you're Matt Damon and it'll still work.

6:30And then the same thing goes with email addresses.

6:33You can put your email address in there

6:36if you want to be contacted for doing some commit.

6:39You can also put johndoe at example.com.

6:42If you don't want to be contacted for some commit,

6:44you can remain anonymous

6:45for whatever reason you want to do.

6:47Git just has to have something there

6:51in order to create the commit.

6:53It has to have that.

6:54So run these two commands,

6:56putting in whatever name or whatever email you want,

6:59and then reattempt the commit again

7:02and it will work this time.

7:04Cool?

7:05Good.

7:06Now, in my case, when I ran this commit message,

7:09something really important happened.

7:10It created a commit.

7:12It created the first version of this code.

7:15And importantly, it created a commit hash.

7:19This is a hash that hashes all of the code

7:23inside of your project.

7:24And it is a unique and quick way to identify your commit.

7:29We're going to talk more about this in an upcoming video,

7:33but just know that this is what the output looks like.

7:35And the important takeaway right here is the commit hash

7:38along with the commit message that goes inside of it.

7:42Now, when I flip back to cursor here for a second,

7:44let me go to cursor,

7:45we now see the readme.md file is white

7:49and there's no message here.

7:51That means we are at the latest version of this file.

7:56There's no new changes.

7:58If I change it now and I say blah, blah, blah, blah,

8:00like this, and then save the file,

8:03now we have a changed file.

8:06So after just a second, the left-hand side updates

8:10and we now see it's kind of brown with an M.

8:13The M meaning it has been modified

8:16since the last time we've worked with it.

8:19I'll show you how to do some cool stuff

8:21with this in a second.

8:22But now what I'm going to do is I'm going to put something

8:24in my Python file, then stage that and commit it.

8:28So I'll say print, and then I'll tab to auto-complete.

8:32You saw that prompt there for a second.

8:34Let's try that again.

8:35I'll show you what happens.

8:36If I type print, see this subtext, this prompt right here?

8:41I haven't typed parentheses, hello world.

8:43This is the AI that is coming from cursor.

8:47Cursor is auto-suggesting some code that is typically run

8:52whenever we start typing.

8:55And it says like, we think you're going to type hello world,

8:57so you could just hit tab to auto-complete the code.

9:00It guesses what you're going to type next,

9:03which is really cool.

9:04I'll do command S to save this.

9:06Now, if I wanted to stage and commit this via the CLI,

9:10we know I would do git add hello world.py,

9:12and then a git commit with a message.

9:14But if I want to do this from cursor,

9:16I'm going to go into the source control tab right here,

9:19and I see right here's the changes.

9:23I see hello world.py,

9:25and I have some buttons that come right after this.

9:30To stage the changes, basically like clicking git add,

9:34all I have to do is click the plus sign.

9:37Now I see this file is staged for committing,

9:39which is really cool, right?

9:41When I want to make a commit,

9:43I can type in my commit message and say,

9:46added hello world.py right here in the text bar,

9:51and click the commit button.

9:53I'll sign it again, in my case,

9:56because I've set it up to do that,

9:57and you won't have to deal with it.

9:59Now I have two commits,

10:03and we see the commit tree going up in this direction.

10:07Here's the first commit, which I can click on,

10:10and it shows me what happened in the first commit.

10:13Here's the second commit, which I can click on,

10:16and it shows me what happened in this commit.

10:19I'll close out of this for a second

10:21and show you some other cool things, like I promised.

10:23Right here, we still see I have unstaged

10:28and uncommitted changes to readme.md.

10:31What were those changes, I wonder?

10:33If I click on this, it shows you a before

10:38and an after view of what has happened.

10:41This is what the last commit holds.

10:43This is what the current file on the hard disk holds,

10:47and we see a little plus here

10:49to show that I added this content right here.

10:52Well, that content is nonsense,

10:54and I don't want it in this particular commit.

10:57So what I can do is I can discard these changes,

11:00rolling back to the previous commit,

11:03by hitting the little undo error.

11:05If I give that a click,

11:06it says we're going to undo all these changes

11:08and roll back to what you had in the previous commit.

11:11When I click discard file, there it goes.

11:14So now when I look in my readme.md file,

11:17there it is as it currently stands.

11:20So I can say added some legit text,

11:25command S to save that.

11:27I see the change, I stage the change,

11:32and I say updated readme.

11:36I commit the change, and now down here,

11:39I have my third commit showing in the commit tree.

11:43So this is staging and committing code

11:47that we can now see how it has changed

11:50from one version to the next.

11:52The big takeaway here is we stage one file at a time,

11:56typically, when we're done working with that file.

12:00And once we're done working with all the files

12:02we want to change, then we make our commit.

0:00So in that last video, you might be thinking to yourself,

0:03the secret sauce is really down here,

0:06where we start tracking the changes

0:09of each one of these commits.

0:11This is known as the Git log.

0:14And what Cursor has done here,

0:16and VS Code for that matter,

0:17because this is really a VS Code fork,

0:20is we have visualized the Git log.

0:25So I'm actually first going to talk about the Git log,

0:29or at least from the Cursor perspective before we move on.

0:32Let's make another change.

0:34I'm going to come back in here,

0:35and I'm going to update one of the given lines.

0:39We're going to change header goes here

0:40to now something like beginning source control lessons.

0:47That's a good header right there.

0:49So I've changed this given line, I've modified it.

0:52I'm going to come in here,

0:53I'll stage it and I'll change updated,

0:56read me header, nice and descriptive.

0:59I know what's going on,

1:00and I'm not worried about publishing the branch right now.

1:02Right now I see I've got a new commit message down here.

1:08So when I see the updated read me right here,

1:10I can click on it and I can see what's changed.

1:13Let's hover over this for a second

1:15and take a look at what's going on.

1:17It's kind of hard to see, so I apologize for that.

1:19If I click, you can kind of zoom in and see.

1:21First of all, we can see the date and time

1:25that this commit was made.

1:27We see the message updated read me header.

1:30We see one file was changed and then this is interesting.

1:33It shows one insertion and one deletion.

1:36Anytime you update an existing line of code,

1:40Git sees that as a delete and recreate, delete and insert.

1:47So you're not going to see a change.

1:49You're going to see delete and insert.

1:52In fact, up here in the comparison,

1:54we're going to talk about this more in the next video,

1:56we see this as a minus and a red box.

2:00So we visualize this as a deletion.

2:02And then we see the same line, line one,

2:05as a plus and then a green box as new code.

2:10So Git will always see an updated line

2:13as a delete and reinsert.

2:15That's a really important thing to understand.

2:17Back down here again,

2:18we see I'm currently on the main branch

2:22and then this is that Git hash.

2:25More on that in just a second.

2:27Now, just for fun, to make this interesting,

2:29I'm going to create another new file.

2:32We'll call this tester.py.

2:36And I'll put just some, any code in here that says print.

2:40We'll say this is a test.

2:44Auto-complete tab, command S save,

2:47stage and commit with created new test.

2:52tester.py file commit.

2:57And of course I see the tree update down here.

2:59So I've got a new commit visualized here.

3:02So we have an idea at least what the Git log

3:06is going to show us from within cursor

3:08and what clicking on each one of these commits

3:11kind of tells you at a very high level.

3:13Let's see what we can do from the CLI.

3:16From the CLI, first of all, if I give this a git status,

3:18I see my working tree is clean,

3:21meaning I don't have any files with changed updates.

3:24We're up to date on everything.

3:26So now what I can do is I can type git log,

3:29and this gives me kind of a text output

3:33of that visualization that we were seeing in cursor.

3:36Why do I like this more?

3:37Well, it's a little more descriptive

3:40and it's certainly a lot more space on the screen

3:43than this tiny little box down here.

3:45Now this takes up the whole screen because I'm on the CLI.

3:49So what do we see?

3:50Starting from the bottom, we see the commit message.

3:54We see the date and time that it was created,

3:57including the time zone.

3:59I'm at minus six right now, that's central time US.

4:02We see the author.

4:04Ah, remember I said you need that username

4:07and email address.

4:09Imagine if you were contributing code,

4:12you were working on open source code

4:14with hundreds of users from all over the world.

4:17When you run git log, you'll see all of their commits

4:21and their contact info.

4:22All of a sudden, the feeling of maybe staying anonymous

4:25for a little bit seems like a good idea

4:26because you don't want anybody to just email blast you

4:29and say, you did this wrong or something like that.

4:31You know what I mean?

4:31Like you could just work on code and contribute

4:34small things without putting yourself out there

4:37if that's what you're worried about.

4:38The next thing is, is there's the commit hash itself.

4:42Again, really important to know your commit hash.

4:45So we see all of these right here

4:48for each one of these commits.

4:50The one at the very top

4:51has a little extra information, doesn't it?

4:54We see this head pointed to main.

4:56What is this all about?

4:58Head is the commit that you are currently on.

5:02You could think about head as the commit

5:06that your code currently shows if you were in cursor

5:09or what is, where am I on the disk right now?

5:14So if we were mapping out these commits,

5:17let's just call this commit one, two, three, four, and five.

5:21It would look like we started with commit one,

5:24we went to commit two, we went to commit three,

5:29we went to commit four, we went to commit five,

5:33and then just an open line.

5:36This open line is known as the head.

5:41You are here.

5:43And importantly, this is all happening on the main branch.

5:48Why do we care about this?

5:49Because if we were working on something

5:52like a bug fix for a second,

5:55maybe the main branch would have gone from commit one

5:58to commit two to commit three,

6:00and then you realize there's a bug.

6:02So you clone the repository

6:04and start a new branch right here for the bug fix.

6:09Maybe the name of that branch is called bug fix,

6:14and you'll have commits from here.

6:17And this will be your commit four, your commit five,

6:21and then maybe this is your current head right here.

6:25So instead, your tree might look like this.

6:30And that's how you know, oh,

6:33my head is currently pointed towards bug fix,

6:36and this is the commit that I'm currently on.

6:40So when we're done, when we're done with all this code,

6:43maybe we make some changes and some edits,

6:45what we'll eventually do is migrate via a formalized process

6:50called a pull request that's way beyond the point

6:53of this skill or this entire course.

6:55There is a formal process for merging that code down here

6:59and updating the code where this becomes the new head

7:03with our bug fix code implemented in it.

7:05The point is, is we see, okay,

7:08this is where my code currently is,

7:10and this is the branch that I'm currently working on.

7:13That's why head and main are here.

7:15Now there's a quicker way that we can look at this.

7:18We can say get log hyphen hyphen one line, all one word.

7:24When I press enter here,

7:25now it shows me an abridged cleaner output

7:28that more mimics what you're seeing in cursor.

7:31It shows you enough of the commit hash to make it unique.

7:36It shows you what the message is.

7:38And in this case,

7:39it shows you where the head and the branches,

7:43but it doesn't tell you anything

7:44like the full commit message.

7:46It doesn't show you the date

7:47and it doesn't show you the author.

7:49So let's now say,

7:50I'm really interested in what the code looked like right here

7:55when I was on this commit.

7:57I can run get checkout.

8:02I'll highlight this commit hash.

8:04Even the abridged will work.

8:05I'll paste it in right here and I'll press enter.

8:08Oh, you are now,

8:11your code has now been changed at least temporarily

8:16to what the code looked like at this commit hash.

8:20Look, if I flip back into cursor even,

8:23ah, my tester file is gone, isn't it?

8:26And if I look at the readme,

8:28we've now reverted the text at the top to header goes here.

8:32Do you see why git is now powerful?

8:35We can go back in time,

8:37changing what the file looked like.

8:39The file on disk,

8:41the readme file and the Python file on disk

8:45is now what it looked like

8:47when this commit hash was created.

8:50Kind of crazy, right?

8:52This is just kind of showing you

8:54where these commit hashes come into play.

8:57Now that I'm ready to go back to the future,

8:58if you will, go back to where we were,

9:01I can do git checkout back to this hash

9:04and now I'm in a good state.

9:07If I say git status,

9:08we see I'm in this hash right here

9:12and I'm on main, just like that.

9:16You can also say git checkout main like this.

9:22And now my branch is on the main branch.

9:25If I say git status like so,

9:27now I am on the latest commit on the main branch.

9:32If I look back here in source control,

9:34it tells me exactly where I am right here on the main branch

9:38with my tester.py file right here on the disk.

9:44So this is the power of git log,

9:47seeing what we've done.

9:48And hopefully it also kind of illustrates the importance

9:52of 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

0:06on code. This again is going to be a very basic intro just to get you familiar with where GitHub

0:13comes into play in the whole world of Git. Basically the idea is we're going to publish

0:19our code onto somebody else's server, onto a GitHub server, where it can either live

0:25privately where only I can access it and other people I invite to collaborate,

0:30or 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

0:42account, sign up for free. Go through that process right now, signing up for GitHub

0:47and sign up for free. I've already got an account so I'm going to sign in.

0:51I am now signed into GitHub and what's really cool about GitHub is you can always remember the

0:56URLs are pretty easy. Whenever you're trying to access your own repo or anybody else's repo,

1:02it is github.com forward slash, then their username, then another forward slash,

1:10and then the name of the repository. So for instance if I'm trying to get to any of my

1:14repositories, I can go to github.com forward slash data knots and there's my profile as well

1:20as a lot of my repositories. If I were to go into the code samples repository, you know the URL is

1:27going to be github.com slash data knocks slash code samples. That's the layout for all of these

1:34repositories. Now this is an open source one, meaning it is a public repository that anybody

1:40can access. What I want to do for the JNCIA DevOps is create my own repository on GitHub

1:48and 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

2:02repository. You can look at this plus button right here, create new, and we'll do new repository.

2:08I'll call this repository JNCIA hyphen DevOps like so and since I haven't created this already,

2:17we can start working on it. You can put a description in here if you want

2:20and then importantly this is where you choose visibility. Is this going to be public for the

2:25world to see or is this only going to be allowed by you? I'm not worrying about adding anything else

2:32at 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

2:43current code up into it. It gives you the CLI commands to run. We're going to use the

2:50git remote add origin. Basically saying we are using, there is a remote repository

2:57and we want it to originate from this URL. Don't worry, our local code is going to get

3:02pushed up there first. We're going to say the branch that we're working on is main

3:07and we're pushing up to our origin which is this URL from our local main branch. I'll copy this

3:17code right here, copy this, jump over here to my URL and I'll paste it in. Press enter a few times

3:25and 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?

3:39So now what we have the ability to do, watch this, I'm going to show you importantly how this

3:44workflow works. You can now think about how this is. We now have on the internet our central server

3:53that has our main branch and on my local computer down here, I also have a copy or a clone

4:04of that main branch. So what I can do on my local computer is I can edit my code,

4:10make 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.

4:29I'll click on runner.py and I'll say print. This is a runner, it's fine and I'll create a stage

4:40and commit and we'll say added runner.py. We'll commit this and notice right here,

4:47now 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

5:00with what exists in the origin. You see origin right there. So these commits all exist in GitHub.

5:09The blue ones do not. The blue ones exist locally on my machine. We can even add some more stuff to

5:16the header. We can say adding new content. We are testing, testing, spell testing correctly,

5:26GitHub, like so. Command S to save it so it's written to the disk. That way GitHub sees that

5:32changes have been made to these files or excuse me, Git sees that changes have been made to these

5:37files. 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

5:56in the tester and just make one new line here and say, you know, print and we'll say this is a second

6:02test. I'm fine with that. We'll stage it and say added second test to tester and commit it. So now

6:13I've got three new commits. The commit hashes, again really important. If I say Git log, we see

6:21now, 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

6:35and I've got three commits, 070FF, 37D74, B6CC4 that don't exist in GitHub. If I refresh this,

6:48you can see the last commit I have is 98D1D02 from 24 minutes ago. That's down here. So it's missing

6:58these three commits right up here. So what do I need to do? I need to push them up into the GitHub

7:08origin. You can click the sync changes button to do that. That will do two things. It will push all

7:15of 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,

7:28dot, dot right here and click push. That takes about one second and now all of my dots right here

7:36look blue and we see the origin and main are kind of in sync right here. If I flip back to GitHub,

7:45boop, and refresh, now I have commit B6CC4 from one minute ago issued right here. Notice on GitHub,

7:57we can also click the eight commits button right here and we see all the commits as they exist

8:03right here. You can click on any one of these commits and see what code was changed. Seeing

8:09the diff, as we call it, the get diff visualized right here in this. Pretty cool, right? This is

8:17also a really important talking factor. If you publish code to GitHub with a secret, a password,

8:26anything that needs to be kept protected, if you publish it into GitHub, deleting that line of code

8:32and 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

8:48sanitize or cleanse all of your code of secrets whenever you can for security reasons before

8:58you make a commit and especially before you publish it or push your code up into GitHub.

9:05So now we've gotten started working with GitHub, a way that you can track the versions of your code

9:12and even publish them in such a way. Why does this matter to you, the learner of a JNCIA exam,

9:21interviews, and resume? I don't know which direction the accents go. Sorry. But the idea

9:30here is now you can demonstrate that you make code and track changes and publish code using

9:39Git, source control, and GitHub. This is a resume builder. Very, very critical to understand that

9:47this is a powerful tool for your career. All right. Now we've covered the very, very,

9:53very 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,

10:05if you want to dig deep, I really recommend a course that we have here. That is the Linux

10:11Professional Institute Certification Exam for DevOps Tools Engineer. There is a lot of content

10:19on how Git from the basics to advanced works and then how collaboration happens with GitHub.

10:27Highly recommend, highly recommend, check out the LPI DevOps Tools Engineer course here at

10:35CBT 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,

0:04paying close attention to some of those Git CLI commands.

0:07You create a new folder for a coding project and want Git to begin tracking changes inside of it.

0:14What command should you run first? Well, it's right here at the top, init.

0:18We have to initialize that repo before we can stage and commit any of the code changes or

0:25begin tracking any of those files. It begins with Git init, which is really going to create

0:31that .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,

0:43but you're not ready to save the snapshot yet. So we've got, we're done with one file.

0:48We're not ready to count this as a new version of the whole project.

0:52What command should we use? Git checkout, Git add, Git log, or Git status.

1:00Right here, we're talking about Git add. We are adding this file to the queue of

1:05files 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.

1:12So we staged the files that we're done with, continue our work,

1:17and then commit them all when we're done.

1:20You discover that your project was working perfectly two commits ago.

1:24You want to temporarily view the project exactly as it existed at that point in time.

1:30What command should you use? Git status, Git checkout with the commit hash,

1:37Git 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,

1:48probably with the one line option, and find out what that commit hash is.

1:52Then we'll run the Git checkout with that commit hash to move the head back in time to that point.

1:59We'll then look at what that code looked like and compare

2:03what was going on, why it worked so well at that point in time.

2:06So this has been refreshing what we learned about Git and source control, the very, very basics.