Get Started Using Git

0:00Welcome to the content I'm working with Git and importantly, welcome to this

0:04course.

0:05Right out of the gate, I'm going to tell you if you've ever watched my content

0:09before,

0:10you're going to see that I'm starting this course out a little bit differently

0:14than I

0:14would have in previous courses.

0:16In previous courses, I would have done things and talking about why are we here

0:20?

0:20What is it that we're really going to study?

0:22What is it that we're going to talk about?

0:24What are the fundamentals and theories behind all of the technologies that we

0:27're about

0:28to cover?

0:29In this course, though, I'm going to do things a little bit differently.

0:33I'm immediately going to dive into something technical and set a big foundation

0:39.

0:39I'm going to talk about source control, specifically using Git.

0:44Now, the first reason for that is it's interesting.

0:47It's fun.

0:48It's a very critical skill for anybody in any form of technology to learn,

0:53whether you're

0:54a software developer, DevOps engineer, systems administrator, network engineer.

1:01This stage of the game, everybody needs to know Git.

1:04You just do.

1:05It's an extraordinarily powerful and important tool to wrap your head around.

1:11But secondly, I also think that starting out talking about theories and why are

1:16we here

1:16is boring.

1:19I don't want to set up something where we can talk for an hour about what is

1:23DevOps

1:23and what is CICD without one of the most important pieces of context.

1:29That's what source control is.

1:32With that source control skill under our belt with some Git under our belt, we

1:37can then

1:38talk about DevOps pipelines in CICD and that light bulb will start flickering.

1:43You'll go, "Oh, I see now how we can use Git as a piece of a bigger picture."

1:50So in this particular course, I'm going to dive right in to using Git.

1:56So get ready because we're about to learn more about source control and in my

2:01opinion,

2:02arguably one of the most important skills in all of technology today.

0:00As promised, I'm going to waste no time diving into this topic.

0:05We're going to start by installing Git and VS Code.

0:09But first, what even is Git?

0:13That really begs the question, what is Source Control/Version Control?

0:22You may have heard one or both of these terms before, Source Control and

0:25Version Control.

0:26They're basically synonyms for each other.

0:29Git is really called Git-S-C-M, which is Git Source Control Manager.

0:35So what is it that it does?

0:37Flip real quick, and we'll talk about it.

0:40Whenever we create an application or write any sort of code, even systems

0:45engineers and administrators,

0:47network engineers and administrators are now writing code to manage their own

0:52infrastructure,

0:54we basically call this an application.

0:56We'll just call it an app.

0:58In our app contains directories, and within those directories, of course, there

1:06are files.

1:07So each one of these can represent a file like this, right?

1:12We kind of get just the overview, the gist of it, that an application is more

1:16than just

1:17a single text file.

1:19It's going to be directories and multiple files.

1:22Now these multiple files, for the most part, usually are forms of text files.

1:28Text files, meaning that any text editor can open it, and it looks like human

1:32readable

1:32text.

1:33A JavaScript file.js is text, a PowerShell file.ps1, text, a Python script,

1:42text, a bash shell

1:45script, text, Ansible or orchestration tools use YAML text.

1:53And sometimes these files aren't text, but they're still really important, like

1:58images

1:59or videos.

2:00These are assets that are used by our application.

2:06So collectively, we have this application right here.

2:10Now the big thing that well happens whenever we create software, especially

2:14with text files,

2:16is these things change.

2:19And what Git, aka Source Control does, is it literally tracks line for line

2:27what is changing

2:28in the application.

2:30If I have a JavaScript file, let's just call this my file.js, and it's 10,000

2:38lines of code,

2:39which it can be.

2:41And we change a single comma on line 2000 and 30.

2:48Just what Git will know this, and it will track it.

2:53And it will literally be able to print an output that says effectively a before

3:00and

3:00an after, where you'll actually see it like with colors and everything, where

3:05it'll say,

3:06you know, minus this one line, where we had, you know, my line period.

3:13And over here, it'll say right over here, plus my line comma.

3:21Git tracks every single change that we make to each one of these files.

3:28And importantly, after we've made a group of changes in Git, we can solidify, I

3:35'm just

3:36going to call this solidify.

3:37It's really got a special name that we're going to learn about as we go.

3:40It can solidify all of these changes as a new version of our application.

3:48And then, of course, now you're kind of seeing where version control comes into

3:52play.

3:53We can track the changes from version one to version two.

3:59And interestingly or powerfully enough, we can revert back to any changes that

4:04we want

4:05whenever we want.

4:06We can say, oh, that didn't work the way we expected to and just roll it back

4:10because Git

4:11has kept track of what has changed in every single file from one step to the

4:16next.

4:16Now, you might also be thinking to yourself, well, hey, I've heard of this

4:20thing called

4:21Git Hub.

4:23Is that the same thing?

4:25No, not quite.

4:27It's similar in nature.

4:29Git Hub is a hub for Git, meaning if we have multiple people, we have a lot of

4:36people

4:36who all want to work on the same application.

4:43Here it is our app.

4:45All of these people can now coordinate their changes using Git on their local

4:52computer

4:53and then synchronize with each other via Git Hub.

4:58How that process actually works is quite in depth and very powerful and very

5:04controlled.

5:05We get into something called branching, which we're going to learn about, of

5:10course.

5:11And then we get into a review process, usually that we call pull requests.

5:16Yes, we're going to learn about that too.

5:19Right now, I just wanted to set up some basic vocabulary, some terms that you

5:23're going to

5:24learn about as we progress along.

5:27So the big thing with Git is that you install it on your local computer and it

5:33helps you

5:33keep track of the changes to your application.

5:37So without further ado, to actually progress through this content, you need Git

5:42.

5:42Now if you have a Linux-based computer or perhaps a macOS machine with X tools

5:47already

5:48installed, you already have Git.

5:52You can fire up your terminal, let me zoom in for you.

5:55If you just type Git and get some sort of output like this, you know you're

5:59good to

5:59go.

6:00Now if you have a Windows computer, it's very likely that you don't have Git.

6:05So click on this website right here, get hyphen@cm.com.

6:09It'll automatically detect your operating system and the download button is

6:14right here.

6:15You'll walk through the basic download and installation.

6:18And when I say basic, it's actually not that basic.

6:21It's actually a very big installation, but importantly, you don't really need

6:27to change

6:28any of the default options.

6:30Before you get to be a true expert in Git, you can just accept all of the

6:35default options

6:36that come with Git.

6:38Now my recommendation to you is once you've installed Git, reboot your computer

6:43.

6:43Git is going to come with some environment variables that you know, a fresh

6:47reboot of

6:47your computer.

6:48It won't leave you fighting through troubleshooting things and figuring out if

6:53the path to the

6:54binaries was added to your path environment, just reboot.

6:57Just install it, fresh reboot.

7:00And then once you've got Git on your computer, that's really half the battle.

7:05The other half of the battle is you're going to need a good code editor and one

7:09that actually

7:10works directly with Git.

7:12In this case, I recommend VS Code.

7:15Now people get very emotional when they talk about their preferred code editor.

7:20Some people can get very snobby about it.

7:22VS Code is an open source visual studio code application.

7:26It was basically a fork of the visual studio application that was primarily

7:31built for

7:32Windows coding way back in the day.

7:35But Microsoft has made a very strong shift to making their stuff as open source

7:40as possible.

7:42And as a result, VS Code has actually become probably the most popular code

7:47editor that

7:48is in existence today.

7:50Now for some developers, like people who work with specific programs or

7:54specific languages,

7:56like Rust, VS Code works.

7:58It might just not be the best.

8:00But for most developers, people who are dealing with JavaScript, PowerShell,

8:04everything

8:05you see right here basically, all of these things, which are very, very popular

8:09programming

8:10languages, VS Code is absolutely perfect.

8:13One of my favorite things about VS Code is that it is extensible.

8:19What does that mean?

8:21It means if VS Code doesn't do what you want it to do out of the box, there's

8:26likely a plug-in

8:29that you can download directly into VS Code that extends its capabilities and

8:35functionalities.

8:36So I highly recommend downloading VS Code and using that to follow along in

8:42this set of

8:43videos.

8:44This is what I'm going to be doing.

8:45Once you've got VS Code installed and get installed, we can fire it up.

8:50So here's what my VS Code layout is going to look like.

8:54It might be a little bit different from yours.

8:56I'll go ahead and go full screen with it like so.

8:59The big thing that you will notice that's different is you'll have all of your

9:03menus

9:03on this side of the screen.

9:06I move these intentionally over to my right hand side of the screen.

9:12There's a reason for that and I'll show you when we get started working on it.

9:16So just know that it'll come back to it.

9:19So some things that you might want to do is you might just want to go into your

9:24settings

9:24and actually bring up things like the color theme.

9:26I know this is kind of silly to say, but the color theme actually matters.

9:31You're going to be staring at it a lot.

9:33So pick something that you like looking at.

9:36For the most part, I'm going to be leaving mine as it is.

9:41So once you've got Git and once you've got VS Code, here's the things that I

9:46want you

9:47to know about VS Code.

9:48Really quickly, you see these blocks over here.

9:52This is where you download extensions, aka those plugins that I was talking

9:57about.

9:57If you give this a click, you'll see that there are a lot of really powerful

10:02extensions

10:02that you can get.

10:04GitHub Co-Pilot is one of the most popular and powerful ones.

10:08This is now where you basically have something like chat GPT built directly

10:13into your code

10:14editor.

10:15It can actually make code recommendations for you as you're typing.

10:20You can even type a comment on the screen that just instructs co-pilot what to

10:25do.

10:26Scaffold a nap for me that does this and it does it right there on the spot.

10:30Now there are some caveats to that like data sharing agreements between co-p

10:35ilot and yourself.

10:36So you wouldn't want to use like the personal addition of GitHub co-pilot on a

10:40corporate

10:41application.

10:45You'll be effectively sharing your source code to Microsoft at that point.

10:46So that's not a good idea.

10:47You'd want to use an enterprise edition of co-pilot.

10:50But this is just kind of setting up some of the things that you can do.

10:55As you can see, I have a lot of Microsoft Azure stuff built into my environment

11:00.

11:00I also have AWS built into my environment.

11:04I have Docker built into my environment.

11:06And this is actually a blockchain called Salana.

11:08These are all programs or extensions that I've added into my environment.

11:13So I wanted you to be aware ultimately that this is the extensions button.

11:18Now this button right here is the source control button.

11:22And again, it is baked into VS Code by default, especially if you have Git

11:26installed on your

11:28computer.

11:29So if you install Git on your computer, reboot it, then install VS Code on your

11:33computer.

11:34You will likely see this Git or source control button right there.

11:39Even this diagram that you see here with the circles and like the, the squiggly

11:43lines here,

11:44even that will make sense to you why they chose that icon as we progress

11:49through this series.

11:51So now that you have a brief understanding of what source control is supposed

11:55to do and

11:56how to get it, we will progress in the next video to getting started.

0:00So now let's get started using Git. There's a few different ways that we can

0:03get started using Git depending on what your project entails.

0:07As you can see here, I've got it brought up on my screen. I am using a folder,

0:13a base folder here called code.

0:16This is where I'm going to do the majority of my work. Now just for fun, right

0:20here, I'm going to create a new folder.

0:23It's right here now. We see it as Untitled folder. And I'm going to call this

0:29app hyphen CLI.

0:31Now I called it app CLI because I'm going to show you how to use Git from the

0:36command line to get started working with this.

0:40But I'm also going to show you how to use VS Code to work with Git as well.

0:48So we're going to do that kind of at the same time. For now, for the very

0:51basics, I've created a folder called app CLI.

0:55This is what's going to contain my app. I'll go into app CLI. I'll create a new

0:59folder in here. We'll call it dummy folder.

1:04And I'll create a new file. But to do that on macOS, I'm going to have to do

1:08this from the terminal.

1:10So I'll go back here to my CLI. I'll go into code. And then I'll go into app CL

1:16I. If I type Ls, I see dummy folder.

1:19I can now do something like touch and say dummy file dot TXT. If I type Ls, one

1:25more, I see now both of these things exist.

1:29Let's edit dummy file dot TXT. I'll just do a nano dummy file dot TXT, dummy

1:36file dot TXT.

1:38And I'll say blah, blah, blah, blah to give it some content right there. If I

1:46say cat dummy file dot TXT, we see now that that file contains the text blah,

1:53blah, blah.

1:54So get is not doing anything yet. I haven't told get to start tracking any of

2:00the changes that exist within this particular folder.

2:05If I want to start tracking changes within this particular folder, all I have

2:11to do is type get in it as an initialize a get repository.

2:16Now understand we are here in the app CLI folder. Underneath this is a folder.

2:26That's my dummy folder and underneath here is also my dummy file dot TXT.

2:38So you see here I am in app CLI. If I say get in it right here in app CLI, this

2:48is going to track the contents of app of anything within app CLI.

2:53It's not going to track the folder app CLI itself. It's just going to track the

2:58contents. So basically I'm in the root of my project and I run get in it from

3:04right there.

3:05I press enter and it says initialized an empty get repository directly in that

3:12path. It's a hidden folder called dot get.

3:16So if I actually type LS right here, you don't see anything if I type LS AL.

3:21Now we actually see the hidden repository of dot get.

3:26And if I type LS AL dot get we actually see there's a lot of extra stuff that

3:33goes in this get repository.

3:37Now most of this is stuff that you will likely not have to encounter, but as

3:42you get really deep into your get journey, there are some reasons that you may

3:48need to come in here and adjust some of the settings of what get is doing.

3:53This is again a highly advanced section. You don't have to worry about the dot

3:58get folder right now.

4:00The only thing I'll say is that if you ever go, oh man, I just blew this

4:04repository and get set up up.

4:07You could actually delete the dot get folder and start over if that's what you

4:11ever need to do.

4:13I'll show you another use case for that in a bit.

4:16Now this is if you want to start a get repository manually. There are a lot of

4:22applications though that automatically do it for you.

4:26Check this out. I'm going to go up back into my code directory here and I'm

4:32going to type in px create react app and we'll call this app VS code.

4:38Now what this is going to do is this is actually going to scaffold a full but

4:43basic react JS application, which is now way later down the road just known as

4:48react app.

4:49But just so you know, this is a JavaScript website that it's going to create

4:53just the full frame of it.

4:55And importantly, this is going to come with a get repository already initial

5:00ized and already to track changes by default.

5:04It's going to create a folder called app VS code and all of the contents and

5:09the get repository will be within that.

5:13So when I press enter here, it's going to take a second to scaffold the whole

5:16thing. I'm going to let it do its thing.

5:18I'm going to let it run because it can take a minute or two and we'll come back

5:21to it when it's done.

5:23Okay, so it does take a minute or two and if I scroll up, there are actually

5:28some interesting outputs right here noticed initialized a get repository.

5:34Then it goes through some things like downloading and installing dependencies

5:39261 packages are looking for funding removed a package audited 1544 packages

5:46found some vulnerabilities.

5:48But then right here created a get commit. This is not something that we've

5:54talked about yet, but a commit is solidifying that whatever the current

5:59contents of this folder are whatever the text files say at this point is a

6:05version of our application.

6:07We are committing to saying that the current state of all of these files is a

6:13current version. So as this application was going when I said create a react

6:19app it created a basic react app while starting it get repository and then when

6:26it was done, it created the first commit which effectively means that this is

6:34version one of the application.

6:36It did this automatically. So with the first commit in place and version one

6:41being solidified now any changes that we make to these files will now be

6:46tracked.

6:48This stands in contrast to what we did manually before before we did we initial

6:55ized a repository, but we never made that first commit.

7:00So it's not really tracking any changes just yet. Now we're not ready to talk

7:05about staging changes or committing changes that's going to come up in the next

7:10video for now I just want you to see what this is actually looking like when we

7:15work with it.

7:16Let me bring VS code back up again and I'm going to go to my file explorer

7:20right here.

7:21It tells me that I don't have a folder open which is totally fine. I'm going to

7:25choose to open a folder will go into the code section here we're going to code

7:31and code there you are.

7:34And for this one I'm going to choose to open app VS code I simply click it and

7:39then say open. So we'll say open and it kind of refreshes the whole thing.

7:45Now what's interesting about this is we see all of the contents of at VS code

7:50right here we see all of the source code all of the assets all of the things

7:56that make the application work.

7:59But also what's interesting is right here see that main it's kind of small at

8:05the very bottom.

8:07But this means that VS code automatically detected the get folder and

8:13understands that there is change tracking now enabled and VS code can now work

8:20directly with get directly in this app editor.

8:24So if I go to app.js right here under the source folder and I change learn

8:29react to learn get like so see right here it's got this white dot up here by

8:35the app.js file.

8:37That white dot indicates that we've changed this particular text file but we

8:42haven't saved it yet.

8:44If I do command s to save it now look what happens see the app file name here

8:50right here at the tab as well as over here on the right hand side has changed

8:56to be this kind of brownish color.

8:59And we also see this M right here.

9:03This is telling me that this file has now been modified from the last time a

9:09commit was taken.

9:12The UI of VS code is already telling me that changes have been made to this

9:18file since the last commit and we have not yet committed these changes to be a

9:25new version yet.

9:27So at this point we're going to stop this video here because what we've done is

9:31we've introduced a couple different ways that get can be initialized where we

9:36can tell it it's time to start getting ready to use get.

9:40If we recap this real quick the two methods were we would either use some sort

9:45of built in tool like create react app that would scaffold a basic application

9:51for me with a get repository already built into it.

9:55This is a very common thing amongst all programming languages or applications

10:01or we would manually create a folder and then use get in it to create the dot

10:07get folder.

10:08For good measure I'll come over here and I'll add the app CLI folder to seeing

10:14this blank space down here under app VS code I can right click and choose add a

10:20folder to workspace.

10:22When I do this I can choose app CLI and click add.

10:28As I make changes to one or the other VS code can keep track of what has been

10:34created or changed in either get repository it knows the changes to dummy file

10:41dot txt belong to the get repository in app CLI and it knows the changes to app

10:48dot JS belong to the get repository in app VS code.

10:53So we can actually work on multiple projects with multiple repositories at the

10:57same time with VS code. So with that being said we'll move on to the next step

11:02which is going to be staging changes and then committing changes.

0:00So in the previous video, we first showed you how to create a new repository

0:05from scratch

0:06using GitInit on the CLI right here.

0:10As we see in VS Code, VS Code does have a coloration of the dummy file.txt and

0:18a U right here.

0:20Because we haven't made an initial commit in App CLI, it really thinks that

0:26there isn't

0:27a starting point yet.

0:28It doesn't believe there are changes to track.

0:31Instead, what we see here, when we see green in VS Code, that means this is a

0:36new file

0:37that was just created and it is currently being untracked for any changes in

0:45Git.

0:46So with our initialized repository in place, what we need to now do is declare

0:52that we have

0:52a starting point and anything after this, we should track them for changes.

0:58So here's how we do this from the CLI because that was kind of the entire point

1:01, is to show

1:02you how to do things from the CLI as VS Code.

1:05I'll move back into App CLI and what I'm going to show you first is Git status.

1:12When we type Git status, it shows me, first of all, what branch we're working

1:16on.

1:17We haven't talked about branches yet, but we will.

1:20It'll show me any existing commits that we have, but we don't have any commits

1:25yet.

1:25And it'll show me any newly created files that we aren't currently tracking.

1:31Interestingly, this shows up as red text in the CLI, but green text in VS Code.

1:38I just think this is kind of funny.

1:40So what we need to do is we need to go through a process called staging and

1:45then we can

1:46actually submit this as a version.

1:49So what you would imagine is we could have lots of files and lots of folders.

1:58We could be making changes here, here, here, here, here, and here.

2:06But maybe for the next version, we really only want to say this file, this file

2:14, and this

2:15file are what we want to put for sure into the next version.

2:20Because maybe I'm still working on this file, this file, and this file.

2:25Maybe those files aren't done yet, but the circled ones are done.

2:29So what we do first is we stage the files that we want to track in the next

2:36version.

2:37That's the step one is staging.

2:42Once all of our files have been staged that we care about, then we can commit

2:48them to

2:48being a new version.

2:50So the way this works is we could do a couple things.

2:54Here's two untracked files that I have the opportunity to stage.

3:00If I want to stage them, you would think I would use a command like get stage,

3:04but unfortunately

3:05for us, it's not get stage.

3:08It is get add.

3:11So if I type get add and then dummy file, dummy file dot TXT like so, and press

3:18enter, now

3:19when I do get status, ah, look at this.

3:22We now see that we have changes that are ready to be committed.

3:27This one has been staged.

3:30Now we do have the ability to unstage a file from the CLI for like, wait a

3:34minute, I didn't

3:35mean to stage that.

3:36I don't want that file to go in the next commit.

3:37We could do that.

3:39We also see that I didn't stage the DS store file.

3:42So it's still down here saying that this will not be committed if we were to

3:47make a commit

3:47right now.

3:49And therefore it's untracked.

3:51Now alternatively, I can just tell it to stage every file in a folder.

3:58This is using get add period.

4:00Again, another one that kind of throws me off, you would think it might be

4:03something

4:04like a star to indicate a wild card, but in this case, the wild card is period

4:09that says

4:10add all untracked or unchanged folders files to the staged section.

4:18So when I say get add period, anything that is currently unstaged will then be

4:23staged.

4:24So now when I say get status, now I see both of these files have been staged.

4:30That's really cool.

4:33Because these files are now both staged, I can now move on to committing them

4:38to be part

4:39of the next version or really the initial version of the CLI.

4:44This is using the get commit command.

4:47There is really only one thing that is mandatory for creating a commit and that

4:53is a message.

4:54Now in my opinion, this is a really important thing to have because if I'm ever

4:59looking

4:59through a history of changes, I'm going to be looking through what each commit

5:05did.

5:05And the thing that I look at is the message.

5:08So in this case, I will say in it, new repo with dummy file dot TXT.

5:16This commit message will now tell me exactly what this commit does.

5:21So when I press enter right here, we now see that the commit message has been

5:26created

5:27and specifically this commit has been given a hash, F6 to E0 FD.

5:34So very cool.

5:35We've now staged and committed changes in the CLI.

5:41What does it look like with VS code?

5:43Let's flip on back here.

5:45Notice now the colors went away because now commit has been made and no changes

5:50have been

5:50made since back here in VS code, specifically my app VS code application that

5:56we have here

5:57I changed app.js didn't I?

6:01And we see that it's currently in the modified state.

6:04I changed it from saying learn react to learn get.

6:08So what do I do here if I want to stage and commit this change?

6:13All I have to do, you'll see this is a lot easier.

6:16We'll go to the source control section and right here it shows me what the

6:21changes are.

6:23One of the most fun things that you can do is actually click on app.js right

6:27here and

6:28it'll show you the before and the after change.

6:31This is a get diff and I'm going to show you more about that later.

6:35I'm going to close this tab here called working tree just to bring it back here

6:39.

6:40When I'm ready to stage this file, all I have to do is click the plus button.

6:45Boop.

6:46Now that file has been staged, we see right here under these stage changes that

6:50it's

6:50there.

6:51Now above it, I can type my commit message and I'll put change app.js to be

7:01learn get.

7:02I click commit and it's done.

7:05Now don't worry about this published branch.

7:08We're not really worried about branches or anything like that just yet.

7:11For now, just know that we've staged and made a commit to app.js.

7:17So the big part about source control was being able to track the changes, how

7:21we went from

7:22one version to the next.

7:24So how do we now do that?

7:27Now that we've made some changes and committed them, that's the next video is

7:30all about.

0:00So now we're going to talk about how we actually track the changes or explore

0:04the changes from one commit to the next.

0:06In order to do this, I'm going to make several changes and several commits

0:10right now.

0:11So we'll say learn get now, command s to save it.

0:15We now see it's modified really quick.

0:18We'll stage and say learn get now commit.

0:23We'll say learn get right now.

0:27How about that?

0:28And we'll command s to save it.

0:32Stage it and learn get right now.

0:36Commit it.

0:37And then oh no, I didn't do an uppercase R.

0:40Learn get right now.

0:44And we'll command s to save it.

0:47Stage it.

0:49Learn get right now.

0:52And commit it.

0:53Great.

0:54So now I've made a lot of changes. You can actually see these changes right

0:59here visually in the incoming and outgoing section, but that's not actually the

1:05part that I care about.

1:06The first thing that I want you to see is how to do it from the CLI.

1:11So I'm going to change out of app CLI for just a second and change into app VS

1:15code.

1:16The first thing I'm now going to type is get log. When I press enter here, I

1:21now see a history of all of the commits.

1:24And like I said, it's going to give you a commit hash.

1:29Each one of these uniquely identifies where we are in the whole timeline.

1:36If you really think of it, lots of times we draw diagrams, especially get

1:40diagrams like so.

1:41This was the initial commit and it was seven D890.

1:48Usually when we talk about commits, we only type enough characters to uniquely

1:54identify it.

1:55In my case, I only wrote five characters here.

1:58The best practice is to write seven characters.

2:02You'll see more about that in just a second.

2:04So this was my initial commit.

2:06Then we progressed and made another commit and it was for a seven for D, then

2:15another commit.

2:16And this was seven nine F a then B one seven then B eight nine.

2:29Now interestingly with B 89091 E, we see this thing right here.

2:35The head indicates where you currently are.

2:39So specifically where our head is is pointed in this direction.

2:45This is where the head is.

2:47And if we were to make another commit, it would be coming after this commit.

2:52That's what the head indicates.

2:54The indicates if you make another commit, it's going to come after this commit

2:58right here.

3:00Now main indicates what branch we're on.

3:03We haven't talked about branches yet, so don't feel overwhelmed.

3:06Just understand that right now our head means we're on this commit.

3:11We have the ability to put our head really anywhere.

3:15But that's an advanced topic that we're not quite ready yet.

3:20I just want you to be able to run GitLog and be able to quickly identify where

3:25you currently are.

3:27So when we're in VS code and we're looking at all of this code right now, this

3:34code is coming from this head.

3:38If I were to move my head down here to seven nine F a four, we would now be

3:45looking at the code in VS code as of seven nine F a four.

3:51So visually this is a really important thing to do.

3:55Another thing that you can do is if somebody asks you what commit are you

4:00currently working on, you can say GitLog minus one and it just shows you the

4:07exact commit where your head is.

4:10And importantly, I can also see the message right here.

4:14Learn Git right now.

4:16This is why I think the Git messages are really important.

4:19Now this is a lot of output on the screen.

4:22If you need something a little bit more concise, you can say GitLog, hyphen hy

4:28phen one line and press enter and there we go.

4:33Now, only do we see the stream of Git commits that we have.

4:36It's also a bridge to show us the seven characters instead of the full hash.

4:42So all we see here is the seven characters are head and the message.

4:48We also interestingly before this before I go on when we did the GitLog, when

4:53we see the full commit above, we also see who the author is and when this

4:58commit was made.

4:59We don't get to see this on one line.

5:02One line is really just, hey, show me the hash and show me the message.

5:08So now how do we see something similar to this in VS code?

5:12Well, in VS code, what I have to do here is I actually have to remove my other

5:18workspace.

5:19So if I had to get repositories here, one for VS code and one for app CLI, this

5:24won't really work.

5:26I have to remove one of these.

5:28So I'm going to remove app CLI.

5:30Now that I only have app VS code on the screen, I know that I've only ever

5:35changed app.js.

5:37I can right click on app.js and say open timeline.

5:41When I open timeline, I now see the history of all of these commits right here.

5:48So right here where I say learn Git now, remember that one?

5:52I can click on that and it shows me specifically what that commit changed.

5:58Again, showing me a Git diff.

6:01It's kind of like looking back in history to an exact moment in time, which is

6:05pretty cool, right?

6:07So this is how we can begin to explore the history from VS code as well as the

6:14CLI using Git log

6:16or just the timeline of a specific file in VS code.

0:00So now let's check out GitDiff, a really powerful way to see from the command

0:04line what's changing.

0:06In this case, I'll change this to be all caps, learn Git right now, but I'm not

0:11going

0:11to stage and commit this just yet.

0:13I'm going to flip back to my terminal here and in VS Code, I'm simply going to

0:19type GitDiff.

0:21When I press Enter, boom, I get in how put that's showing me on the CLI what's

0:27changing

0:28for each of these files.

0:30In this case, I only changed one file and it begins right here by showing me

0:34the Diff

0:36using Git between file A and file B. Even though file A and file B are actually

0:44the same

0:45file, aren't they?

0:47They're from source app.js and source app.js.

0:52So how do we tell which file is which because they're the same file?

0:56Why is there an A and a B?

0:58A is the file as of last commit.

1:04B is the file that is on disk currently.

1:11Remember, I've made a change, I've saved it, I haven't staged your committed it

1:16, but

1:16it's saved, so it lives on disk.

1:19And that's what we're looking at here with B. With A, that's just what we had

1:23in the last

1:24commit.

1:25And that's why we see comparing A to B. Now the index is nothing that you

1:29really need

1:29to worry about.

1:31This is part of the commit hash and then some extra data about file B right

1:37there.

1:37When we look at A and B, we see that A, the A file, really only have file delet

1:45ions.

1:45And what this really means is we either deleted lines entirely or we replaced

1:51lines.

1:52When we replace lines or change text in a line, it sees that as deleting the

1:58line and

1:58recreating it.

2:00So that's why A is telling us we had deletions and B had additions.

2:05Now the interesting thing here is this section.

2:09What is this showing me?

2:11This is showing me that this output below right here is going to be comparing

2:16file A and

2:17file B.

2:19What we see below is starting on line 15 and then going down seven lines.

2:26So if I just look at it, if I spy on it right here, this is really where it

2:30starts with target

2:31blank, right?

2:33So if I flip on over to VS code, this way, line 15 target blank.

2:40And sure enough that corresponds right here.

2:43So when I'm looking at this output below, line 15 is where we're looking at the

2:49starting

2:50point for both file A and file B.

2:54And then we go down.

2:56The subtraction means that this red line right here was happening in file A.

3:02And the addition

3:04right here is what happens in file B.

3:08And this is quite literally what a get diff shows us.

3:12It's really similar to what we did in VS code, wasn't it?

3:15We got to this in VS code for a couple different ways.

3:18The first one is I went to look at my changes.

3:22I can literally see in the changes right here, app.js and just click on it.

3:26And it shows me what was the before and what was the after side by side.

3:30I really, really like that.

3:32Of course, we also had the timeline.

3:34Remember we can come here and look at the timeline and look at what changed

3:39from these

3:39commits to the present from the previous commit.

3:43So that was a really useful thing in VS code.

3:45But other interesting things that you can do with get commit where to go right

3:51there or

3:51get diff, I should say, we could do get log one line like so and then compare

3:57what changed

3:58between commits right here.

4:00We could say get diff and show me what changed on B 17 versus 7, 9, F a.

4:10Ah, look at that.

4:12Actually, I think I got that backwards.

4:14Hang on, let me do this.

4:15We got to say the starting point was 7, 9, F a like so.

4:21And the ending point was B 17.

4:24So it looks like this.

4:26Yeah.

4:27And that lines up with what my message says right here.

4:29We have learn get now.

4:31We deleted that line and changed it to learn get right now with a lowercase r

4:36like this.

4:37So from the CLI, we still have a huge amount of functionality with not only

4:41looking at

4:42our history, but also seeing what changed throughout our history using get diff

4:47.

0:00So our challenge should we choose to accept it is to refresh our knowledge on

0:05everything that we just learned about Git.

0:07So we're really just talking about starting from scratch.

0:10Do you have the ability to get started from scratch and understand how to track

0:16changes with a perfectly new project?

0:19Now everything that we can do we can do from the CLI or from VS Code.

0:24I'll let you pick which one you want to do, but I did specify the Git CLI just

0:30to kind of challenge yourself to learn these commands.

0:32I promise you, you know, expert software developers are very comfortable with

0:39the CLI.

0:40So if you really want to impress somebody in a job interview, get comfortable

0:44with the CLI.

0:45So here we go.

0:46I am going to go into my code folder.

0:49I'm going to make a new folder called challenge demo. I'll change into

0:54challenge demo and I'm going to create a new file.

0:57We'll call it my file.py for Python script.

1:01I'll do nano my file.py and I'll just print something to the terminal.

1:06Hello world like so just very, very, very basic Python stuff.

1:12So that is step one, create a new folder and inside of it a text file.

1:17Now step two initialize a Git repository using the Git CLI.

1:23So here I am. I'm in the root of my folder.

1:26I'd like to track any changes that get made or done from here.

1:31So I know the command is get in it.

1:34And if I give it an LSAL, the hyphen L really lists everything including the

1:39hidden folders.

1:40I now see the dot Git hidden folder is there.

1:44You have you say LS, hyphen L dot Git.

1:47Now you can actually see all of the stuff that makes Git Git, which is pretty

1:52cool.

1:52Stage and commit the first commit.

1:54So here we are.

1:56If I look at this, I've got my file.py and if I give it a git status, nothing

2:01has happened yet.

2:02It for the most part isn't tracking any changes in my file.py from here because

2:09it's not told to.

2:10We don't have any initial commit to track a change from.

2:13So I know that I can either do git add and specify my file.py directly or I can

2:20do git add dot period to add everything in there.

2:24So now that the staging is done.

2:28If I do git status, we now see a file is staged and it's ready to be committed.

2:32I'll say git commit and specify initial commit as my commit message.

2:38So now that that's done, I've staged and committed the file.

2:42I have an initial commit and now we're tracking changes from here.

2:46So git status tells me nothing to commit.

2:49We're working tree is clean.

2:51Make an edit your text file.

2:53So make some changes.

2:55Let's do nano my file dot.py prints.

2:58Hello world print.

3:00I am working.

3:04And close it out and save it a quick git status confirms.

3:09We've now modified this file.

3:11We can either restore it back, which we'll talk about later or we can stage

3:14this change.

3:15So stage and commit the change explaining what is changed.

3:19git add period to stage it git commit.

3:24I did a new print line and enter.

3:30Now we've made the commit.

3:32What's our next step?

3:33Explore the git log to confirm this commit worked.

3:37git log tells me sure enough I see my initial commit when it was committed who

3:42created it

3:43and the hash.

3:45Then the commit that we're currently on based on the head again, we'll talk

3:48more about

3:49that in an upcoming set of videos.

3:51We added a new print line when that was done who did it and what the new commit

3:55hash

3:55is finally compare your last commit to the first.

4:00So we can say get diff like this doesn't really show us much right because we

4:05don't have

4:05a working change to compare an old commit to a new one.

4:10We got to think about the starting point.

4:12The starting point was 8 6 a for e.

4:15The ending point was 0 f f to 4 when I compare these two.

4:20Now we actually see the changes the differences in the a file in the b file and

4:25where this new

4:26addition was.

4:27So with that being said, we've now refreshed ourselves on the beginning

4:31fundamentals

4:32of working with git.