Introduction to Source Control with Git

0:00[AUDIO LOGO] Hi, guys. My name is Trevor Sullivan, and welcome back to another CBT Nugget skill. In this skill, we are going to be exploring the basics of Git, which is a command line tool that you can use in order to manage a version control for your software projects. If you're already familiar with the essentials of Git and you've been hands on with Git and you already understand how it works, then feel free to skip this skill and move on to another skill within this course that you are more comfortable with.

0:42But in the meantime, the rest of us are going to stick around and understand the essentials of using Git. After all, this skill is part of the Git lab training course here. And in order to understand the benefits of using a hosted service like GitLab, we first need to understand the essentials of Git itself. Now, Git evolved around 2005. It's been around for some 17 years at this point in time. And Git was designed to be a decentralized version control tool that is also cross-platform as well.

1:17Now, a lot of historical version control systems were centralized. And essentially what that meant is that in order for you as a software developer to work on your version control system, you had to have a direct connection to the server that hosts all of the source code for your software projects. Now, Git and Mercurial and other types of decentralized version control tools out there have the concept of decentralization where you have, basically, separate copies of your version control repository.

1:50And only by agreement do individual developers on a development team actually determine that a particular server, like GitHub or GitLab or any other Git hosting service, is going to be considered the source of truth for a given software project. But when you as a developer are working on a local copy of your development repositories that are stored in Git, you actually have a full replica of everything that is stored on the server, you can make changes to your heart's delight on your local file system.

2:25And once you're ready to push those changes and share those changes with other developers on your team, then you can go ahead and initiate the push operation to essentially synchronize the changes from your local development system up to the centralized server. There's a lot of benefits to using a decentralized tool like Git or Mercurial, which is a very similar tool to Git, and that allows you to work in an offline state. Maybe you are in a remote country and you don't have a good internet connection, or maybe you're up on a plane, maybe you travel frequently and you're consistently working with Git repositories in airports and on airplanes and that kind of thing.

3:08And so having the ability to work in an offline capacity where you don't have to check out files from the server is a huge benefit to modern day software development. So Git is really the de facto standard tool. Everything in software these days pretty much revolves around storing code and even data inside of a Git repository. Now, you want to use Git to store changes to your source code because Git is very efficient at storing changes to your source code over time.

3:42So there's a few different reasons that we use Git. Number one is we want to keep a log or a history of the changes that we are making to our software projects. That allows us to go forward and backward in time, and look at different snapshots of our application source code over a period of time. And we can see what has changed over that period of time. We can also see when exactly changes were made. So not only can we see what has changed, but we can also see when exactly those changes were made.

4:13And this is really important, because if we're trying to debug a particular problem in our application, if we're trying to track down some kind of bug, or look at when a particular feature was introduced into our software application, we can go back in history and look at the history of our source code repositories that are stored in Git. And we can determine when exactly a feature was introduced or when exactly a bug was introduced into our program. So we can determine the scope of impact of that feature or of that bug on our application because we can see when those changes were made.

4:50A third thing that is very beneficial of using Git is that you can see exactly who made a specific change to your software project. And this actually goes line by line in your source code. It's not just who's the last person that changed this file, no. It's actually even more specific than that. And it'll actually show you, on a specific line of a source code file, who the last person was to change that specific line and when that particular change was made.

5:21And then really the fourth key benefit of using Git is collaboration. You can work as an individual, maybe a hobbyist software developer. But if you're working in an enterprise and you're working with a large team environment, maybe you've got seven or eight developers on your development team, you guys need some place to centralize your source code so that everybody can push and pull changes from the other developers and synchronize all those changes across the entire development team. And that is exactly the type of problem that Git is intended to solve.

5:55So we're going to be exploring how to use Git from a very basic level, and then progressively, we'll build some more advanced understanding of some of the more advanced Git features that are available in the platform. But for starters, when you are very first-- for the very first time when you're working with the Git CLI tool-- it is a command line tool that you can use to manage your source code, the first thing that you're going to do is to create what's known as just a Git repository. Now, you initialize a new Git repository by using the Git CLI tool, and running the init subcommand.

6:29And that's going to create a new repository on your local file system on your development workstation. Now, at that point, once you've initialized a repository on your local development system, nobody else knows that it exists and nobody else has access to it because presumably, you are the only person that has access to your particular development workstation. However, if you want to share it with other developers, you can do that using a centralized Git hosting platform, which we'll talk a little bit about later. Now, once you've created your empty Git repository, the next thing that you'll do is you'll use a text editor, oftentimes something like Vim, or Notepad, or Microsoft Visual Studio code, or really any integrated development environment that you'd like to use, And you'll create these different source code files in your Git repository.

7:19And then you'll commit those changes-- commit is a specific operation in the Git CLI. And essentially what you're doing is you're taking a snapshot of those files that you've made changes to or imported into your Git repository, and you are persisting them into the Git working tree. It's basically a hierarchy of files and branches. And basically, that's where your source code stays so that you can see the history of the changes to your source code over time.

7:50So Git is a CLI tool that runs on Windows. It runs on Mac OS. It runs on Linux. You can pretty much run Git anywhere that you have the ability to run a Linux system, you can run it inside of containers. Git pretty much runs anywhere. And while the Git CLI tool is probably the most popular way of interacting with Git repositories, there are lots of third party applications that allow you to work with Git repositories without having to necessarily drop into using the Git CLI, which sometimes can be a little bit too much for more amateur users of the Git version control tool.

8:27Now, once you've got this Git repository created and you've committed your changed files into that repository, that's really the basis of establishing a history of your source code changes over time. However, you're probably going to want to share this source code with other developers. So we'll talk about how that's going to work in our next video. I hope this has been informative for you, and I'd like to thank you for viewing.

0:11Hi, guys, and welcome back. So in the last video, we discussed some of the benefits of using Git to version control your application source code or plain text files really of any type. It doesn't have to be application source code. You could store recipes in plain text files if you want to. You could store data in a JSON format or a YAML format or any other plain text format and persist that into a Git repository as well. It doesn't have to be application source code that you're working with.

0:42But in general, that's what most software projects are going to consist of at a bare minimum. Now once you've established a Git repository and you've been creating some files inside of that Git repository, you're probably going to want to share that data with some other developers, right? You're going to have other developers on your team that are going to want access to the data that is persisted inside of that Git repository. If you've created a Git repository on your local file system, on your development workstation, then, of course, nobody else is going to be able to access that across the network.

1:17You'd have to have some way to share that Git repository with other developers. And that's where the concept of Git remote comes into play. So because Git is decentralized, your copy of your Git repository that you have on your local file system is exactly just that, it's just a copy of a Git repository. You could literally take that repository, you could put it into a zip archive, and then email it to somebody else. They could extract that file system onto their local dev system.

1:48And then they'll be able to access the Git repository, but it'll be a totally separate copy from the one that you have on your development workstation. And of course, we don't want to introduce those kinds of inconsistencies where one developer is working on one copy and another developer is working on a totally different copy and they're making changes that are potentially going to conflict with each other. So instead, what we do is we set up what's known as a Git remote. In Git terminology, a remote is basically a remote location somewhere on the network where you can push and pull changes for your Git repository to and from.

2:27There's lots of different solutions available for hosting Git repositories remotely. Some of those examples are things like GitLab. Gitlab.com is a Sas service, or software as a service, that allows you to basically just sign up for an account. You don't have to host any infrastructure or install any applications or set up network firewalls or anything like that. You can go straight out to GitLab, you can sign up for an account, and you can actually create Git repositories there. And then make copies of them locally or you can just take a local Git repository that you have and then push it up into GitLab.

3:05There's lots of other hosting solutions as well. GitHub is a major competitor to GitLab. They offer the same ability to just create an account and log in and create repositories, and then synchronize those repositories together. So rather than your development team having to have access to your laptop, which is prone to failure, there's very little redundancy that's built into laptops, especially from a storage perspective. Instead, we can leverage a hosted service and basically push and pull all of our changes to one of these managed services instead of from an individual's laptop.

3:43That's a much more robust solution for us as a development team to be able to collaborate on a software project. Now, there's other self-hosted solutions as well. So one popular solution out there is this green logo right here, which is called a Gitea. There's also another service out there, which is a fork called GOGS. G-O-G-S. And these are just self-hosted options that you have to basically host your own Git server. And everybody can just kind of agree that that Git server that you're hosting internally within your organization is going to be the source of truth.

4:19And so everybody's going to push and pull their Git changes, their commits for different file changes to that central server instead of a Sas service like a GitHub or GitLab. Now, the major cloud providers like Microsoft Azure or Amazon Web Services, as well as Google Cloud platform, all offer hosted Git solutions as well. So you can basically just create a repository inside of your cloud account. And then you can store your source code within those places as well.

4:49Now, there's a lot of benefits to using a GitLab as a hosted Git solution rather than some of these other platforms. And we'll discuss what some of those are. First of all, GitLab is a self-hosting solution as well. So very similar to Gitea and GOGS, GitLab can actually be self hosted. You can run it to on at your own infrastructure at no additional cost to you, except, of course, for the cost of the infrastructure itself. Now, GitHub does have a GitHub enterprise version that you can technically self-host on your own infrastructure.

5:25However, it's a much less flexible solution. It does require payment in order to self-host a GitHub. And so in general if you're looking for a self-hosted option that is kind of an all-in-one comprehensive solution, GitLab is generally going to win out over GitHub just because GitLab does start with a free tier. Now, one set of features that you'll oftentimes find within hosted Git solutions like GitLab or GitHub or Microsoft Azure's DevOps service is some value add tools on top of just Git hosting by itself.

5:59So you've got more than just the ability to store your application source code within a Git repository. You also have things like issue trackers and wikis for documentation for your software projects. You've also got the ability to handle merge requests so that developers can merge code branches together in a more calculated and code reviewed fashion. And so there's a lot of benefits to using one of these hosted Git platforms. But you don't strictly have to use all of those advanced features of those platforms.

6:30You can just use them as a Git server, where you're going to push and pull your changes to and from. So get the CLI tool has a built in subcommand called the Remote Subcommand that allows you to configure your local copy of your Git repository with a remote network location of where you want to store a copy of the changes that you're committing to your local repository. So if you started out by creating an empty local Git repository and then you added some files into that repository on your local development system here, you can go out to one of these hosted Git solutions, you can sign up for an account, you can create a repository, and then you can use the Git CLI to configure that remote hosting service as a Git remote.

7:19And that configuration will get persisted into your local copy of your Git repository. And then any time that you want to synchronize changes between your local Git repository and the Git hosting solution that you've selected to use, you can simply use the Git Pull and Git Push commands in order to synchronize those changes. And all of the other developers that are on your development team can also use their Git CLI tools to similarly push and pull changes to and from that hosting service so that everybody is working on a consistent copy of the source code within that particular repository.

7:58I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hey, guys, and welcome back. So in the last video, we discussed at a high level why you would want to use a Git remote hosting service in order to have a copy of your Git repository in a central location so that all of your software development team can collaborate on it. Now, I wanted to discuss-- before we jump into a hands on demonstration of the Git CLI itself and potentially some other graphical software tools that you can use to interact with Git repositories, I wanted to discuss some of the common commands that you'll come across when you are working with Git.

0:47And feel free to take a screenshot of these subcommands, and just use it as a quick reference in case you ever need to use this in order to refer back to when you're using the Git CLI hands on. So over here, we've got a bunch of common Git subcommands that you'll find when you are working with the Git CLI. And one of the most common commands that you're going to come across is this commit operation right here. So basically, when you commit files into a Git repository, what you're doing is you're telling Git that you want to take a snapshot of any changes that have been made to certain files, and you want to persist them into the Git index.

1:27The Git index is essentially the central database, so to speak, of any source code files that reside within your project. And that actually includes file deletions as well. If you delete a file from your code project, there's still a history of the existence of that file and the contents of that file within the Git index so that if you ever have to roll back to an earlier version of your application code, then you're able to do that and recover any lost files.

1:57So the commit operation is one of the most common operations that you're going to perform within Git because that is how your persisting any code changes into your project. However, there's a command you're going to want to get familiar with before you use the commit command, and that is the add command. So Git has something known as the working tree. And basically, when you want to stage changes to commit them into the Git index, you first need to add them, you need to stage those changes as files that you want to commit.

2:31For example, let's say that you made changes to 20 different files all at the same time. But maybe only five or six of those files you actually want to persist into your Git index at a single time. So rather than forcing you to stage and commit all 20 of those changes, Git actually allows you to selectively pick certain files that you want to commit, and then you can add that to a staging environment. And then once you stage those changes, you can then commit all of those changes within a single snapshot to your Git index.

3:09Now, when you perform a commit operation here, you have the opportunity to specify what's known as a commit message. And that commit message is basically just a-- literally just a message or a note to other developers who are examining your Git repository. So that they can understand a summary of what changes were made in that given commit, or I'll use the term snapshot, of your application source code. So over time as you're making changes to your application source code, you're making bug fixes, you're maybe making security enhancements, you're adding in new features, to your application code, you're able to specify this commit message so that other developers on your team can see that you've committed a significant chunk of code back into the project, and they can summarize the changes without having to go line by line through each of the files in the project to understand what has changed.

4:07So the commit is basically your opportunity to say, in plain English, what has changed and why. Now, other commands that are going to be helpful when you're working with the Git CLI are things like Git diff, because Git diff is going to allow you to see what changes have been made to certain files that are then going to be committed into the Git index. So this is really nice because if you forget exactly what changes you've made and you're not quite sure what changes are going to get committed and then pushed up into your Git remote, the Git diff command allows you to see exactly what has changed line by line, so that you can determine if those are things that you actually want to commit into your Git repository or not.

4:52Another useful command, a very common command that you're going to come across, is the Git log command. One of the key benefits of using the Git repository in order to manage your application source code is that you can go back in history and you can see what has changed, and who changed it, and when those specific big changes were made. And the Git log command is exactly how we go back and look at the commit history within our repository. And we can see a summary of all the comets that have been made to our code branch, and that allows us to see what kind of changes have been made over time, and just get a big picture view of our Git repository so that we can see what's going on with our history there.

5:37Also, another key command here. This correlates back with the add command here. So any time that you're making changes to your application files within your Git repository, those files are going to be in a series of different status levels. So when you're creating new files inside of a Git repository, you are adding that file into the project. Or if you're deleting a file, you're literally just deleting that file out of the project. So there's an add operation, there's a delete operation, there's a modification operation as well.

6:08So if you have an existing file but you're only making changes to parts of that existing file, but that file still is going to exist after those changes were made, then that would be considered a modification event. And then there's another status as well, which is the untracked status where you've created a file inside of your Git repository, but that file has never been committed into the Git index. And so Git basically has no awareness of it. So that's what Git considers something to be untracked according to Git itself.

6:40The Git status command is really essential because it's going to show you which files have been added to the project, which files have been modified, which files are going to be deleted, and which files are simply untracked because they've never been committed into that Git repository. Now, when it comes to working with remote environments, so if you are working with a local copy of your Git repository that is from a remote server somewhere, maybe you've set up a new development laptop and you're trying to just get copies of all your application source code repositories from these remotes onto your local development system, you're going to want to be familiar with the clone command.

7:25So the Git clone command is going to allow you to point to a external URL. Oftentimes, an SSH or HTTPS based URL for security reasons. And that's going to allow you to tell Git specifically which repository out on a remote server you want to make a copy of on your local development workstation. So that will cause the Git CLI to reach out to that remote Git server, it will download a copy of the Git repository onto your local file system, and you'll have a complete replica of what's stored up on the server so that you can make any changes that you need to to your software project.

8:04And then you can then commit those changes, and then push those changes back up to the Git remote. Now, in terms of managing the remote configuration itself. So let's say, again, that you create a local Git repository that's completely empty. You don't start out by hosting it up on a hosting service, you just create a local one. If you want to be able to then push that Git repository up to a Git hosted platform such as GitLab, then you'll need to use the Git remote subcommand here in order to configure the remote URL to point to the server where you want to be able to push changes to.

8:44So that any time that you're making changes to your local copy of that Git repository and then call the Git push command in order to push those changes to that remote, the remote subcommand is going to allow you to configure all of the different locations, all the different servers where you may want to push and pull that source code from and to. So these are just some of the common commands that you'll come across. I probably should have added pull and push in here as well. Because any time that you're working with a remote Git server, you're going to need to be pushing and pulling those changes as well.

9:17But these are some of the essentials that you'll see when you're working with the Git CLI. So now that we understand some of the conceptual things behind Git itself. Let's actually run Git CLI itself and explore how Git repositories work. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hey, guys and welcome back. So in the last couple of videos, we've taken a look at how Git works at a high level, and now I wanted to spend a few minutes going over some of the basics of the Git CLI with you so that you can understand the basics of how Git it works. Now, again, Git is a cross-platform CLI tool.

0:32So you can run it on the Windows platform, which I happen to be using on my local development workstation here. However, you could also use it on Mac OS. So if you've got a MacBook, MacBook Pro, or a Mac Pro development workstation, or even if you've got a Linux workstation, or a server that's running up in the cloud, like a virtual private server, then you can run Git on all of those locations as well. So for the purposes of this demonstration, what I've done is just gone out to a cloud service called Linode here.

1:04This is a really nice cloud hosting platform that allows me to very easily spin up Linux virtual machines. I can just come in here and very easily create a new Linux machine. And I'm going to be using Ubuntu Linux here for this particular demo. And one of the nice things about Ubuntu is that it oftentimes comes with Git pre-installed on it. So most likely, you won't even have to worry about installing Git on the Ubuntu Linux distribution. So I've set up this virtual machine, and I've SSHed into that virtual machine.

1:34So of course, you'll want to have SSH set up so that you can access that virtual machine. But once you've got a shell on that remote Linux virtual machine, we should be able to use the Git CLI tool in order to work with Git repositories. Now, if you run the CLI here with no arguments, no command line arguments, then you're probably going to notice a whole bunch of different subcommands getting printed out here. And it can look a little bit intimidating if you are new to Git. But as I previously mentioned, just refer back to this list of common commands that I've got right down here, because this is going to show you just the basics of what you need to do to get started.

2:16So in order to create a new Git repository, we're just going to focus on the Git init command. And all that's going to do is create a new working directory, and initialize it with our Git base repository. And then from there, we can start to add files into our project. So let's take a look at how that command works. So if I try to run Git init, it's going to use whatever directory I am currently located in order to create the Git repository.

2:48So when you SSH into a Linux virtual machine, you're typically going to get placed into your home directory by default. So because I'm logged in as the root user, it's going to put me in the slash root directory. But I don't want the slash root directory to be a Git repository. I want to create multiple Git repositories potentially under my home directory. So as a relatively standard practice, regardless of what development workstation I'm doing, I tend to just create a Git directory to hold all of my different Git project directories.

3:20You don't have to follow that convention if you don't want to, but I typically like to keep my Git project directories separate from all the other data on my development workstation. And by putting that under a Git directory, that usually works pretty well for me. So I'm going to CD or change directory into that Git directory, and then I'm just going to create a new directory here called CBT Nuggets. And then I'm going to CD into that directory. And then I'm just going to run LS command here. And as you can see, there are no files or directories in there because we just created this directory.

3:55So what it can do now is inside of the CBT Nuggets directory, I can run the Git init command, and that is going to initialize this directory as a Git repository. Now, what happens when we initialize a directory as a Git repository you might be asking yourself? Well, let's run LS and see what we have. Well, it looks like nothing has changed. We don't have any files or directories in our project. Or do we? So if we run LS-LGA here, you can see that we actually do have a hidden directory.

4:31So any directory or file that starts with a period on a Unix system is considered a hidden directory or file. And so as you can see, the .Git directory is hidden from our default view so that we don't accidentally mess with that directory because that is the Git index. All of the changes that we make to our repository are persisted under that Git directory here. So as you can see, if we just run LS by itself we don't see that .Git directory, and that helps us avoid accidentally making changes to it.

5:04So at this point, we do have a Git project here. And so I can actually run a Git log command, and you can see that the branch that I'm currently on, which is the master branch, does not have any commits yet. So we have not established a commit history, so we can't examine the history with the Git log command because we haven't made any changes to this project yet. All we have is what's known as a Git branch, and we'll talk about branches more in a separate skill that talks specifically about how branches work.

5:35But for now, when you initialize a new repository in Git, you automatically get a master branch with no commits on it. So let's go ahead and add some data into our Git project here. To do that, all you need to do is create a file. So you can do something as simple as a touch command, which literally will just create a file with a particular file name. So let's say that we're developing a bash script. So I'll say, touch script01.sh. And so if we do LS now, you can see that file has been created in our directory.

6:09And if we do an LS-L for long list format, you can see that file is 0 bytes in size because we haven't actually put anything into that file. It's just an empty file. So at this point, we could go ahead and create some additional files. We could say touch script02, touch script03. And so now we've got several different files inside of our Git project, but there's nothing inside of them. So typically, what you want to do is use a text editor like maybe Vim, for example, to make some changes to a file.

6:40So let's say Vim script04.sh. And down here, you'll see that Vim says that this is going to be a new file because we didn't create a script04.sh. But let's go ahead and just add in some text here into this file. So I'll do a shebang here and say, user bin env bash-- and then we'll just say echo Hello. And then we'll do an escape and then we'll do a colon wq to save and quit Vim. And let's just do an LS-L. So now, sure enough, we have a fourth script file here.

7:15It's 32 bytes in size. And if we were to try to run that, we're actually going to get an error because we have not yet made that file executable. So I'm just going to do a chmod +x to make it executable, and we'll plug-in a script04.sh. And now if we do LS-L, should see that it has the execute bit enabled, and the colorization has changed to indicate that it's now executable. So we'll dot slash script04.Sn. And sure enough, our source code has run successfully, albeit being very, very simple in nature.

7:48So we have initialized a new Git repository, and we have our branch. Let me just do Git branch here. And we've got our master branch. And we don't have any commits yet. So in our next video, we'll go ahead and commit these changes to our Git repository, and then we'll start to see some history on our master branch because we'll have made some commits to that branch. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hi, guys, and welcome back. So in our last video, we initialized a new git repository, and then we created some files inside of that project. But we saw that we don't have any history in our git repository just yet. So if I run the git status command, which is another command that I recommended you refer to in the git sub-commands history here.

0:37What we can do is to run git status, and you'll see that git is telling us that there is a bunch of untracked files inside of our git repository. So we've got scrip01, 2, 3, 4.sh. And all of those files in red right here are considered untracked files as far as our git repository is concerned. And you'll see even right here it says No commits yet, and we're currently still on that master branch. We're not going to leave the master branch at this point in time.

1:08So it tells us right here how we can include these files into our git repository. And the way that we do that is by using this git add command. So you can specify git add and then one or more file names to add them to the working tree in the git repository. And then once they're in the working tree, then you can go ahead and actually commit them. You can commit those staged changes to the git index, and that will persist those changes into your git repository.

1:43So the only file that we've actually put any file contents into is script04.sh here, so that's the only one that I'm going to commit. Now you can commit empty files into a git project, but in general, there's not really much reason to do that. So I'm just going to do a git add on script04.sh here. And so now, if we rerun the git status command again, you're now going to see that under the staged changes right here, it says that it's going to add a new file into the git repository, which is script04.sh But the other files that we didn't add any contents to are still going to be considered untracked files even once we've made a commit to our git branch here.

2:30So now what we can do is commit these changes or commit this one change, I should say, this one new file into our project here. So we'll do git commit. And then typically, with a git commit, you're going to need to specify a commit message, and you're also going to need to specify your email address and your name as well. And that's the metadata that git uses to insert into the commit message so that you can see who made the change and what their email address is so you can get in touch with that developer and contact them in case you have an inquiry about the changes that they made.

3:09So you'll want to, as the git CLI recommends right here, you want to run the git config command here to configure your email. So we'll say trevor.sullivan@cbtnuggets.com. And then there's another attribute that we want to configure here called user.name as well. So you can just paste that in. And then I'll just say Trevor Sullivan and make sure that I have double quotes around that. And so now that's going to configure my name and email address from here on after, and the git CLI is going to use that in order to make additional commits in the future.

3:45So now we're going to run the git commit command. And if I don't specify any command line arguments, you're going to see that it opens up our default text editor. In this case, it's nano, and it's explicitly asking us to enter a commit message for your changes. So you actually do have to specify a commit message. So I'm just going to quit out of here, control-X to close nano, and you're going to see that it aborts the commit operation because we didn't specify a commit message.

4:15So what we typically do is use the --message parameter here. And this allows us to specify in quotes here a friendly message to the other developers on our development team so that we can inform them of what the changes are contained inside of this specific commit or snapshot of our source code changes. So I'll just say Adding new script with hello message. All right, and that's the only parameter that we have to specify on the commit command here.

4:47So as you can see under the summary of what was committed into our git repository here, only one file was changed. We added one new file into our project, and that file had three insertions, basically meaning three new lines that have been added into that particular file. And the name of that file is, of course, script04.sh. So git is very explicit with us. It's telling us what our commit message was. It's giving us the hash prefix for that particular commit.

5:20Git tracks everything as a hash so that you can see exactly when changes were made. And so this hash is going to change every single time that you make changes to different files, and you commit those changes into a repository. So it's showing us a summary of all the changes that were committed in the single commit to operation. So now that we've got a commit in our git history, we should be able to run the git log command. And sure enough, you can see that we have a commit. We can see the full hash of the commit.

5:51And then, we can see who made the change, when exactly that change was made, and we can also see a summary of what the changes were inside of that commit by seeing the commit message printed out right down here. So at this point, we might want to make some enhancements to that script file. So we could open that up in vim again. So open up vim script04.sh. And then I'll change this echo to say Hello World from CBT Nuggets!

6:23instead, and then we'll go ahead and save those changes with a colon wq in vim. And now, if we do a git status command again, now you're going to see that script04.sh no longer shows up under the untracked files section here. Instead, because the script04.sh file was already stored. It was already committed into the git index. We can now see that the status of that one file is now modified because the state of that file, something about that file, was changed between the last commit and the current state of that file that has not yet been committed.

7:03Now you'll notice that the change has not been staged for commit at this point. So if I try to run a git commit and say fixing, let's say --message equals Fixing hello message in script04, you can see that because this change was not staged for committing, the change was not actually made to that file. It says no changes were added to commit and so we actually have to use the git add command in order to stage that change first.

7:37So we'll say git add script04.sh. And you can oftentimes use tab completion if your shell has that built in for the file name there. And so now we're going to rerun a git status command. And now you can see that we have successfully staged that change, and so the next time that we make a commit the changes, the modifications to script04 are going to get persisted into the git index. So now what we'll do is go ahead and do a git commit with that Fixing hello message in script04 message here.

8:10And now you can see that one file has been changed-- not added-- because we've already committed that file before, but that file has now been changed, and one new line has been inserted into that file, and one line has been deleted from that file. So the old line was removed, the new line was added, and that shows how efficient git is with storing data because it's not creating an entire replica of the file with the changes. It's only recording the individual lines that actually have to be changed, and so git is very efficient from a storage perspective.

8:48It does not require a significant amount of storage to make changes to your simple plain text source code files. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[AUDIO LOGO] Hey, guys, and welcome back. So in the last video, we took a look at how to commit files into our Git repository and create this ongoing history or log of all the changes that we've made to our Git repository. So this is really helpful because the git log command is showing us a summary of the history of what changes have been made inside of our Git repository.

0:36Now, if this log gets longer and longer and longer, which inevitably it will, sometimes you're going to need to hone in on a specific file and look at the differences between one commit and another commit. So let's check out the git diff command, which is another command that I've put on my little quick reference here, and this is going to allow us to see unstaged changes in our working directory-- so what's the difference between a previous commit and our current working directory-- or we can actually use it to also see the difference between two different commits within our history.

1:15So let's check out the git diff command and how it's going to work here. So we can run git diff and then "dash dash help." That'll open up the help for this particular command in our terminal here, and as you can see, we are able to specify a commit hash that we want to use to examine our differences against. So, basically, it's going to take our current working directory and it's going to compare it to a commit that we point it to.

1:46Also, we can specify multiple commits if we want to examine the differences between two different commits, by specifying the hashes for each of those commits that are-- that we want to get the difference on. So at the moment, we just have two different commits in our history here. We simply made a new file, initially called script04.sh. And then we went into that file and we modified it, and we changed the text of that file. But remember, we only changed one line, but there's actually three lines in that file.

2:20So if we just cat script04.sh right here, you can see we've got three lines. We've got our shebang, an empty line, followed by the echo line here, and the echo line is the one that we changed between the first commit, with this hash, and the second commit, with this hash starting with 07f. So what we can do is use the git diff command to compare our current working directory, so let's run git status and just make sure that there's no pending changes, right?

2:51And so according to git status here, script04.sh has not been modified since the last commit, with 07f, so what I'm going to do is just do a git log. I'm going to copy this hash from our first commit to my clipboard, and then we're going to run a git diff and tell it to use that hash, that commit hash, to compare our current working directory, which matches the latest commit, with that very first commit that we had.

3:22So as you can see, it's going to print out the list of changes that were made to all of the different files that were changed between our current state and this commit starting with 568a. So as you can see, any file lines that have the minus sign in red here are going to be lines that were removed, and then the green text with the plus sign that is prefixing it are any lines that have been added to a particular file here.

3:52And it shows you a couple of lines of context around the lines that were changed, just so that you can get some context to understand exactly where that change was made in the file. It's also going to show us the summary of changes here. So you can see one line was deleted, one line was added, and we have a total of three lines in this file right here. And the file name, of course, is script04.sh. So as you can see, the git diff command is showing us the changes between this original commit and the latest commit that our current working directory matches.

4:30However, what would happen if we actually changed that file in our current working directory? So let's say that we added in another line here that does maybe an apt-get update and apt-get upgrade, which is just a very common command that is going to upgrade all of the installed packages on the Linux system here, very popular in DevOps scripts, and so now if we do a git status, you're going to see that we have a modified file that has not been staged for commit yet, right?

5:02We have not done a git add to stage that change for a future commit, but we can use the git diff command here. We're going to use the exact same command to compare with the very first commit in our project, but now you can see that we have five lines in our file rather than just three at this point, because we have added yet another line and another blank line here to our file. So what's happening here is that when we run the git diff command, it's actually comparing our current working directory-- even though we haven't committed this new change where we've added these two new lines to our file, it's actually taking our current state of that file, not just the latest commit, and then it's comparing it with this historical commit, where we originally had the line just saying "echo hello" here.

5:54So any changes that even have not yet been committed are going to be shown by the git diff command, so this is useful for looking at any unstaged changes that have not yet been committed into your repository. And this'll give you a much better insight into what's going to be committed into your file when you do actually run a Git commit. So now I'll add yet another commit here. I'll say "git add script04.sh" right here, then we'll just do a git commit with a message saying "Adding apt-get commands."

6:34Cool. And so now if we take a look at our Git log, we should have three commits now, right? So now we've got this one starting with cc4, and so if we were to specify multiple commits, we could say, hey, Git, I want you to show me the differences between 568 and cc4, right? So what I can do is copy these commit hashes to my clipboard, and then we'll do a git diff command here. And then we'll paste in both of those different hashes here, and we do want to make sure we have the full hash.

7:04And now you can see that it's showing us a very similar output from before. But what we're doing in this case is we're specifying that we want to start at commit 568 and go to commit cc4, right? And so what we could do instead of doing that is say, I want you to show me the differences between 07f and cc4, right, because I want to see only the changes between the last two commits here. And so instead of saying 568, I'll paste in the 07f right here, and now you're going to see that in this case, only the blank line with the apt-get command line has been added between the second-to-latest commit and the latest commits here.

7:44So I can look at any history here and say, I want you to show me, between this commit and this commit, somewhere in history, and Git is going to show us what changes were made between those different commits to different files inside of our Git repository. I hope this has been informative for you, and I'd like to thank you for viewing.