Introduction to Source Control with Git

0:00[AUDIO LOGO]

0:11Hi, guys.

0:12My name is Trevor Sullivan, and welcome back

0:14to another CBT Nugget skill.

0:16In this skill, we are going to be exploring the basics of Git,

0:21which is a command line tool that you can use in order

0:24to manage a version control for your software projects.

0:28If you're already familiar with the essentials of Git

0:31and you've been hands on with Git

0:33and you already understand how it works,

0:35then feel free to skip this skill

0:37and move on to another skill within this course

0:40that you are more comfortable with.

0:42But in the meantime, the rest of us

0:44are going to stick around and understand

0:47the essentials of using Git.

0:49After all, this skill is part of the Git lab training course

0:53here.

0:53And in order to understand the benefits

0:55of using a hosted service like GitLab,

0:58we first need to understand the essentials of Git itself.

1:02Now, Git evolved around 2005.

1:05It's been around for some 17 years at this point in time.

1:09And Git was designed to be a decentralized version control

1:13tool that is also cross-platform as well.

1:17Now, a lot of historical version control systems

1:20were centralized.

1:22And essentially what that meant is

1:23that in order for you as a software developer

1:25to work on your version control system,

1:28you had to have a direct connection to the server that

1:32hosts all of the source code for your software projects.

1:35Now, Git and Mercurial and other types of decentralized version

1:40control tools out there have the concept

1:43of decentralization where you have,

1:46basically, separate copies of your version control

1:49repository.

1:50And only by agreement do individual developers

1:55on a development team actually determine

1:57that a particular server, like GitHub or GitLab

2:01or any other Git hosting service,

2:03is going to be considered the source of truth

2:06for a given software project.

2:09But when you as a developer are working

2:11on a local copy of your development repositories

2:15that are stored in Git, you actually

2:17have a full replica of everything

2:19that is stored on the server, you

2:21can make changes to your heart's delight

2:23on your local file system.

2:25And once you're ready to push those changes

2:28and share those changes with other developers on your team,

2:32then you can go ahead and initiate the push operation

2:35to essentially synchronize the changes

2:37from your local development system up

2:40to the centralized server.

2:42There's a lot of benefits to using a decentralized tool

2:46like Git or Mercurial, which is a very similar tool to Git,

2:50and that allows you to work in an offline state.

2:54Maybe you are in a remote country

2:57and you don't have a good internet connection,

2:59or maybe you're up on a plane, maybe you travel frequently

3:02and you're consistently working with Git repositories

3:05in airports and on airplanes and that kind of thing.

3:08And so having the ability to work in an offline capacity

3:11where you don't have to check out files from the server

3:15is a huge benefit to modern day software development.

3:20So Git is really the de facto standard tool.

3:23Everything in software these days

3:25pretty much revolves around storing code and even data

3:29inside of a Git repository.

3:31Now, you want to use Git to store changes to your source

3:35code because Git is very efficient at storing changes

3:40to your source code over time.

3:42So there's a few different reasons that we use Git.

3:44Number one is we want to keep a log or a history of the changes

3:49that we are making to our software projects.

3:52That allows us to go forward and backward in time,

3:55and look at different snapshots of our application source code

3:59over a period of time.

4:00And we can see what has changed over that period of time.

4:05We can also see when exactly changes were made.

4:08So not only can we see what has changed,

4:10but we can also see when exactly those changes were made.

4:13And this is really important, because if we're

4:15trying to debug a particular problem in our application,

4:19if we're trying to track down some kind of bug,

4:21or look at when a particular feature was introduced

4:24into our software application, we can go back in history

4:28and look at the history of our source code repositories

4:31that are stored in Git.

4:33And we can determine when exactly a feature was

4:36introduced or when exactly a bug was

4:39introduced into our program.

4:41So we can determine the scope of impact of that feature

4:44or of that bug on our application

4:47because we can see when those changes were made.

4:50A third thing that is very beneficial of using Git

4:53is that you can see exactly who made a specific change

4:57to your software project.

4:59And this actually goes line by line in your source code.

5:03It's not just who's the last person that changed this file,

5:06no.

5:06It's actually even more specific than that.

5:08And it'll actually show you, on a specific line of a source

5:13code file, who the last person was

5:15to change that specific line and when that particular change was

5:20made.

5:21And then really the fourth key benefit of using Git

5:24is collaboration.

5:25You can work as an individual, maybe a hobbyist software

5:28developer.

5:29But if you're working in an enterprise

5:31and you're working with a large team environment,

5:34maybe you've got seven or eight developers on your development

5:37team, you guys need some place to centralize your source code

5:42so that everybody can push and pull changes

5:44from the other developers and synchronize

5:46all those changes across the entire development team.

5:50And that is exactly the type of problem

5:52that Git is intended to solve.

5:55So we're going to be exploring how

5:57to use Git from a very basic level,

5:59and then progressively, we'll build

6:01some more advanced understanding of some

6:03of the more advanced Git features

6:05that are available in the platform.

6:07But for starters, when you are very first--

6:10for the very first time when you're working with the Git CLI

6:13tool-- it is a command line tool that you

6:15can use to manage your source code,

6:17the first thing that you're going to do

6:19is to create what's known as just a Git repository.

6:22Now, you initialize a new Git repository

6:25by using the Git CLI tool, and running the init subcommand.

6:29And that's going to create a new repository on your local file

6:34system on your development workstation.

6:36Now, at that point, once you've initialized

6:38a repository on your local development system,

6:40nobody else knows that it exists and nobody else has access

6:44to it because presumably, you are the only person that

6:47has access to your particular development workstation.

6:50However, if you want to share it with other developers,

6:52you can do that using a centralized Git hosting

6:55platform, which we'll talk a little bit about later.

6:58Now, once you've created your empty Git repository,

7:01the next thing that you'll do is you'll

7:03use a text editor, oftentimes something like Vim, or Notepad,

7:07or Microsoft Visual Studio code, or really any integrated

7:11development environment that you'd like to use,

7:14And you'll create these different source code

7:16files in your Git repository.

7:19And then you'll commit those changes--

7:21commit is a specific operation in the Git CLI.

7:25And essentially what you're doing

7:26is you're taking a snapshot of those files

7:29that you've made changes to or imported into your Git

7:32repository, and you are persisting them

7:35into the Git working tree.

7:38It's basically a hierarchy of files and branches.

7:41And basically, that's where your source code

7:43stays so that you can see the history of the changes

7:47to your source code over time.

7:50So Git is a CLI tool that runs on Windows.

7:52It runs on Mac OS.

7:54It runs on Linux.

7:55You can pretty much run Git anywhere

7:57that you have the ability to run a Linux system,

8:00you can run it inside of containers.

8:02Git pretty much runs anywhere.

8:04And while the Git CLI tool is probably the most popular way

8:08of interacting with Git repositories,

8:10there are lots of third party applications

8:13that allow you to work with Git repositories

8:16without having to necessarily drop into using the Git

8:19CLI, which sometimes can be a little bit too much for more

8:23amateur users of the Git version control tool.

8:27Now, once you've got this Git repository created

8:29and you've committed your changed files

8:31into that repository, that's really

8:34the basis of establishing a history of your source code

8:38changes over time.

8:39However, you're probably going to want to share this source

8:42code with other developers.

8:43So we'll talk about how that's going

8:45to work in our next video.

8:47I hope this has been informative for you,

8:48and I'd like to thank you for viewing.

0:11Hi, guys, and welcome back.

0:13So in the last video, we discussed

0:14some of the benefits of using Git to version

0:18control your application source code or plain text files really

0:22of any type.

0:23It doesn't have to be application source code.

0:25You could store recipes in plain text files if you want to.

0:29You could store data in a JSON format

0:32or a YAML format or any other plain text format

0:35and persist that into a Git repository as well.

0:38It doesn't have to be application source

0:40code that you're working with.

0:42But in general, that's what most software projects

0:45are going to consist of at a bare minimum.

0:48Now once you've established a Git repository

0:50and you've been creating some files inside of that Git

0:53repository, you're probably going

0:55to want to share that data with some other developers, right?

0:59You're going to have other developers on your team

1:01that are going to want access to the data that is persisted

1:05inside of that Git repository.

1:07If you've created a Git repository on your local file

1:11system, on your development workstation, then, of course,

1:14nobody else is going to be able to access

1:16that across the network.

1:17You'd have to have some way to share that Git repository

1:20with other developers.

1:22And that's where the concept of Git remote comes into play.

1:26So because Git is decentralized, your copy

1:29of your Git repository that you have on your local file system

1:33is exactly just that, it's just a copy of a Git repository.

1:38You could literally take that repository, you

1:40could put it into a zip archive, and then

1:42email it to somebody else.

1:43They could extract that file system

1:46onto their local dev system.

1:48And then they'll be able to access the Git repository,

1:51but it'll be a totally separate copy from the one

1:54that you have on your development workstation.

1:57And of course, we don't want to introduce

1:58those kinds of inconsistencies where

2:00one developer is working on one copy

2:02and another developer is working on a totally different copy

2:05and they're making changes that are potentially going

2:07to conflict with each other.

2:09So instead, what we do is we set up

2:11what's known as a Git remote.

2:14In Git terminology, a remote is basically a remote location

2:19somewhere on the network where you can push and pull

2:22changes for your Git repository to and from.

2:27There's lots of different solutions available for hosting

2:30Git repositories remotely.

2:32Some of those examples are things like GitLab.

2:35Gitlab.com is a Sas service, or software

2:38as a service, that allows you to basically just sign up

2:42for an account.

2:43You don't have to host any infrastructure

2:45or install any applications or set up network firewalls

2:49or anything like that.

2:50You can go straight out to GitLab,

2:52you can sign up for an account, and you can actually

2:54create Git repositories there.

2:56And then make copies of them locally

2:59or you can just take a local Git repository

3:01that you have and then push it up into GitLab.

3:05There's lots of other hosting solutions as well.

3:07GitHub is a major competitor to GitLab.

3:11They offer the same ability to just create an account

3:14and log in and create repositories,

3:16and then synchronize those repositories together.

3:19So rather than your development team

3:21having to have access to your laptop, which

3:24is prone to failure, there's very little redundancy

3:27that's built into laptops, especially

3:29from a storage perspective.

3:32Instead, we can leverage a hosted service

3:35and basically push and pull all of our changes

3:38to one of these managed services instead of from an individual's

3:43laptop.

3:43That's a much more robust solution for us

3:46as a development team to be able to collaborate on a software

3:50project.

3:51Now, there's other self-hosted solutions as well.

3:54So one popular solution out there

3:56is this green logo right here, which is called a Gitea.

3:59There's also another service out there,

4:01which is a fork called GOGS.

4:03G-O-G-S. And these are just self-hosted options that you

4:07have to basically host your own Git server.

4:10And everybody can just kind of agree

4:12that that Git server that you're hosting internally

4:15within your organization is going

4:17to be the source of truth.

4:19And so everybody's going to push and pull their Git changes,

4:22their commits for different file changes

4:25to that central server instead of a Sas service like a GitHub

4:30or GitLab.

4:31Now, the major cloud providers like Microsoft Azure or Amazon

4:35Web Services, as well as Google Cloud platform, all offer

4:39hosted Git solutions as well.

4:41So you can basically just create a repository inside

4:44of your cloud account.

4:45And then you can store your source code within those places

4:49as well.

4:49Now, there's a lot of benefits to using

4:51a GitLab as a hosted Git solution

4:55rather than some of these other platforms.

4:57And we'll discuss what some of those are.

5:00First of all, GitLab is a self-hosting solution as well.

5:04So very similar to Gitea and GOGS,

5:07GitLab can actually be self hosted.

5:09You can run it to on at your own infrastructure

5:12at no additional cost to you, except, of course,

5:15for the cost of the infrastructure itself.

5:19Now, GitHub does have a GitHub enterprise version

5:22that you can technically self-host

5:23on your own infrastructure.

5:25However, it's a much less flexible solution.

5:28It does require payment in order to self-host a GitHub.

5:32And so in general if you're looking

5:34for a self-hosted option that is kind

5:36of an all-in-one comprehensive solution,

5:39GitLab is generally going to win out

5:41over GitHub just because GitLab does start with a free tier.

5:45Now, one set of features that you'll oftentimes

5:47find within hosted Git solutions like GitLab or GitHub

5:51or Microsoft Azure's DevOps service

5:54is some value add tools on top of just Git hosting by itself.

5:59So you've got more than just the ability

6:01to store your application source code within a Git repository.

6:05You also have things like issue trackers and wikis

6:09for documentation for your software projects.

6:12You've also got the ability to handle merge requests

6:15so that developers can merge code branches together

6:17in a more calculated and code reviewed fashion.

6:21And so there's a lot of benefits to using one of these hosted

6:24Git platforms.

6:25But you don't strictly have to use

6:27all of those advanced features of those platforms.

6:30You can just use them as a Git server,

6:33where you're going to push and pull your changes to and from.

6:36So get the CLI tool has a built in subcommand called the Remote

6:41Subcommand that allows you to configure

6:44your local copy of your Git repository

6:47with a remote network location of where

6:50you want to store a copy of the changes

6:54that you're committing to your local repository.

6:57So if you started out by creating an empty local Git

7:00repository and then you added some files into that repository

7:04on your local development system here,

7:06you can go out to one of these hosted Git solutions,

7:09you can sign up for an account, you can create a repository,

7:12and then you can use the Git CLI to configure

7:15that remote hosting service as a Git remote.

7:19And that configuration will get persisted

7:21into your local copy of your Git repository.

7:24And then any time that you want to synchronize changes

7:27between your local Git repository and the Git hosting

7:32solution that you've selected to use,

7:34you can simply use the Git Pull and Git Push commands in order

7:38to synchronize those changes.

7:40And all of the other developers that are on your development

7:43team can also use their Git CLI tools

7:46to similarly push and pull changes

7:48to and from that hosting service so that everybody

7:52is working on a consistent copy of the source code

7:56within that particular repository.

7:58I hope this has been informative for you,

8:00and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hey, guys, and welcome back.

0:13So in the last video, we discussed at a high level

0:15why you would want to use a Git remote hosting service in order

0:20to have a copy of your Git repository

0:23in a central location so that all of your software

0:26development team can collaborate on it.

0:29Now, I wanted to discuss--

0:30before we jump into a hands on demonstration

0:33of the Git CLI itself and potentially

0:36some other graphical software tools

0:38that you can use to interact with Git repositories,

0:41I wanted to discuss some of the common commands

0:43that you'll come across when you are working with Git.

0:47And feel free to take a screenshot

0:49of these subcommands, and just use it

0:51as a quick reference in case you ever need to use this

0:54in order to refer back to when you're using the Git CLI

0:58hands on.

0:59So over here, we've got a bunch of common Git subcommands

1:03that you'll find when you are working with the Git CLI.

1:06And one of the most common commands

1:08that you're going to come across is this commit operation

1:11right here.

1:12So basically, when you commit files

1:14into a Git repository, what you're doing

1:16is you're telling Git that you want

1:18to take a snapshot of any changes that have been made

1:21to certain files, and you want to persist them

1:25into the Git index.

1:27The Git index is essentially the central database, so to speak,

1:31of any source code files that reside within your project.

1:35And that actually includes file deletions as well.

1:38If you delete a file from your code project,

1:42there's still a history of the existence of that file

1:45and the contents of that file within the Git index

1:48so that if you ever have to roll back

1:50to an earlier version of your application code, then

1:53you're able to do that and recover any lost files.

1:57So the commit operation is one of the most common operations

2:00that you're going to perform within Git because that

2:03is how your persisting any code changes into your project.

2:08However, there's a command you're

2:09going to want to get familiar with before you

2:11use the commit command, and that is the add command.

2:15So Git has something known as the working tree.

2:18And basically, when you want to stage changes to commit them

2:22into the Git index, you first need to add them,

2:26you need to stage those changes as files

2:29that you want to commit.

2:31For example, let's say that you made changes

2:33to 20 different files all at the same time.

2:37But maybe only five or six of those

2:39files you actually want to persist into your Git index

2:44at a single time.

2:45So rather than forcing you to stage and commit all 20

2:49of those changes, Git actually allows you to selectively pick

2:54certain files that you want to commit,

2:57and then you can add that to a staging environment.

3:01And then once you stage those changes,

3:03you can then commit all of those changes

3:05within a single snapshot to your Git index.

3:09Now, when you perform a commit operation here,

3:12you have the opportunity to specify what's

3:14known as a commit message.

3:16And that commit message is basically

3:18just a-- literally just a message

3:20or a note to other developers who are examining your Git

3:24repository.

3:25So that they can understand a summary of what

3:29changes were made in that given commit,

3:32or I'll use the term snapshot, of your application source

3:35code.

3:36So over time as you're making changes to your application

3:39source code, you're making bug fixes,

3:42you're maybe making security enhancements,

3:44you're adding in new features, to your application code,

3:48you're able to specify this commit message so

3:51that other developers on your team

3:53can see that you've committed a significant chunk of code

3:57back into the project, and they can summarize the changes

4:00without having to go line by line through each

4:03of the files in the project to understand what has changed.

4:07So the commit is basically your opportunity

4:09to say, in plain English, what has changed and why.

4:14Now, other commands that are going to be helpful

4:16when you're working with the Git CLI are things like Git diff,

4:20because Git diff is going to allow you to see what changes

4:23have been made to certain files that are then going to be

4:27committed into the Git index.

4:29So this is really nice because if you

4:31forget exactly what changes you've made

4:34and you're not quite sure what changes are going

4:37to get committed and then pushed up into your Git remote,

4:40the Git diff command allows you to see exactly what has changed

4:44line by line, so that you can determine if those are things

4:47that you actually want to commit into your Git repository

4:50or not.

4:52Another useful command, a very common command

4:55that you're going to come across, is the Git log command.

4:57One of the key benefits of using the Git repository in order

5:01to manage your application source code

5:04is that you can go back in history

5:06and you can see what has changed, and who changed it,

5:09and when those specific big changes were made.

5:12And the Git log command is exactly how

5:15we go back and look at the commit history

5:18within our repository.

5:19And we can see a summary of all the comets

5:22that have been made to our code branch,

5:24and that allows us to see what kind of changes

5:27have been made over time, and just

5:29get a big picture view of our Git repository

5:33so that we can see what's going on with our history there.

5:37Also, another key command here.

5:38This correlates back with the add command here.

5:41So any time that you're making changes to your application

5:44files within your Git repository,

5:47those files are going to be in a series of different status

5:50levels.

5:51So when you're creating new files inside

5:53of a Git repository, you are adding that file

5:56into the project.

5:58Or if you're deleting a file, you're

5:59literally just deleting that file out of the project.

6:02So there's an add operation, there's a delete operation,

6:05there's a modification operation as well.

6:08So if you have an existing file but you're only making changes

6:11to parts of that existing file, but that file still

6:14is going to exist after those changes were made,

6:17then that would be considered a modification event.

6:20And then there's another status as well,

6:22which is the untracked status where you've created a file

6:25inside of your Git repository, but that file has never been

6:30committed into the Git index.

6:32And so Git basically has no awareness of it.

6:35So that's what Git considers something

6:36to be untracked according to Git itself.

6:40The Git status command is really essential

6:43because it's going to show you which files have been added

6:47to the project, which files have been modified,

6:50which files are going to be deleted,

6:52and which files are simply untracked because they've never

6:56been committed into that Git repository.

7:00Now, when it comes to working with remote environments,

7:03so if you are working with a local copy of your Git

7:07repository that is from a remote server somewhere,

7:11maybe you've set up a new development laptop

7:14and you're trying to just get copies of all your application

7:17source code repositories from these remotes

7:19onto your local development system,

7:21you're going to want to be familiar

7:23with the clone command.

7:25So the Git clone command is going

7:26to allow you to point to a external URL.

7:30Oftentimes, an SSH or HTTPS based URL for security reasons.

7:35And that's going to allow you to tell Git specifically

7:39which repository out on a remote server

7:42you want to make a copy of on your local development

7:46workstation.

7:47So that will cause the Git CLI to reach out to that remote Git

7:51server, it will download a copy of the Git repository

7:54onto your local file system, and you'll

7:56have a complete replica of what's stored up on the server

8:00so that you can make any changes that you need

8:02to to your software project.

8:04And then you can then commit those changes,

8:06and then push those changes back up to the Git remote.

8:10Now, in terms of managing the remote configuration itself.

8:14So let's say, again, that you create a local Git repository

8:18that's completely empty.

8:20You don't start out by hosting it up on a hosting service,

8:23you just create a local one.

8:24If you want to be able to then push that Git repository

8:28up to a Git hosted platform such as GitLab,

8:32then you'll need to use the Git remote subcommand here

8:36in order to configure the remote URL to point to the server

8:41where you want to be able to push changes to.

8:44So that any time that you're making changes

8:45to your local copy of that Git repository

8:48and then call the Git push command in order

8:50to push those changes to that remote,

8:53the remote subcommand is going to allow

8:56you to configure all of the different locations,

8:58all the different servers where you may want to push and pull

9:01that source code from and to.

9:04So these are just some of the common commands

9:05that you'll come across.

9:06I probably should have added pull and push in here as well.

9:09Because any time that you're working with a remote Git

9:13server, you're going to need to be pushing and pulling

9:15those changes as well.

9:17But these are some of the essentials

9:18that you'll see when you're working with the Git CLI.

9:22So now that we understand some of the conceptual things

9:24behind Git itself.

9:26Let's actually run Git CLI itself

9:29and explore how Git repositories work.

9:32I hope this has been informative for you,

9:34and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hey, guys and welcome back.

0:12So in the last couple of videos, we've

0:14taken a look at how Git works at a high level,

0:18and now I wanted to spend a few minutes going

0:20over some of the basics of the Git CLI with you

0:24so that you can understand the basics of how Git it works.

0:28Now, again, Git is a cross-platform CLI tool.

0:32So you can run it on the Windows platform, which

0:35I happen to be using on my local development workstation here.

0:38However, you could also use it on Mac OS.

0:41So if you've got a MacBook, MacBook Pro, or a Mac Pro

0:45development workstation, or even if you've

0:47got a Linux workstation, or a server that's

0:50running up in the cloud, like a virtual private server,

0:52then you can run Git on all of those locations as well.

0:57So for the purposes of this demonstration, what I've done

1:00is just gone out to a cloud service called Linode here.

1:04This is a really nice cloud hosting

1:05platform that allows me to very easily spin up

1:08Linux virtual machines.

1:09I can just come in here and very easily create a new Linux

1:13machine.

1:13And I'm going to be using Ubuntu Linux here

1:16for this particular demo.

1:18And one of the nice things about Ubuntu

1:19is that it oftentimes comes with Git pre-installed on it.

1:23So most likely, you won't even have

1:25to worry about installing Git on the Ubuntu Linux distribution.

1:30So I've set up this virtual machine,

1:31and I've SSHed into that virtual machine.

1:34So of course, you'll want to have SSH

1:36set up so that you can access that virtual machine.

1:38But once you've got a shell on that remote Linux

1:41virtual machine, we should be able to use the Git CLI

1:45tool in order to work with Git repositories.

1:49Now, if you run the CLI here with no arguments,

1:53no command line arguments, then you're

1:55probably going to notice a whole bunch of different subcommands

1:58getting printed out here.

1:59And it can look a little bit intimidating

2:02if you are new to Git.

2:04But as I previously mentioned, just

2:06refer back to this list of common commands

2:10that I've got right down here, because this

2:12is going to show you just the basics

2:14of what you need to do to get started.

2:16So in order to create a new Git repository,

2:19we're just going to focus on the Git init command.

2:22And all that's going to do is create a new working directory,

2:25and initialize it with our Git base repository.

2:31And then from there, we can start

2:32to add files into our project.

2:35So let's take a look at how that command works.

2:38So if I try to run Git init, it's

2:41going to use whatever directory I am currently located in order

2:46to create the Git repository.

2:48So when you SSH into a Linux virtual machine,

2:50you're typically going to get placed into your home directory

2:53by default. So because I'm logged in as the root user,

2:57it's going to put me in the slash root directory.

3:00But I don't want the slash root directory

3:02to be a Git repository.

3:04I want to create multiple Git repositories potentially

3:07under my home directory.

3:09So as a relatively standard practice,

3:12regardless of what development workstation I'm doing,

3:14I tend to just create a Git directory

3:17to hold all of my different Git project directories.

3:20You don't have to follow that convention if you don't want

3:22to, but I typically like to keep my Git project

3:25directories separate from all the other data

3:28on my development workstation.

3:30And by putting that under a Git directory,

3:32that usually works pretty well for me.

3:34So I'm going to CD or change directory

3:37into that Git directory, and then I'm

3:39just going to create a new directory here called

3:42CBT Nuggets.

3:43And then I'm going to CD into that directory.

3:46And then I'm just going to run LS command here.

3:49And as you can see, there are no files or directories in there

3:52because we just created this directory.

3:55So what it can do now is inside of the CBT Nuggets directory,

3:59I can run the Git init command, and that

4:02is going to initialize this directory as a Git repository.

4:07Now, what happens when we initialize

4:09a directory as a Git repository you might be asking yourself?

4:13Well, let's run LS and see what we have.

4:17Well, it looks like nothing has changed.

4:19We don't have any files or directories in our project.

4:22Or do we?

4:23So if we run LS-LGA here, you can see that we actually

4:28do have a hidden directory.

4:31So any directory or file that starts

4:33with a period on a Unix system is considered

4:36a hidden directory or file.

4:38And so as you can see, the .Git directory is hidden from

4:42our default view so that we don't accidentally mess with

4:45that directory because that is the Git index.

4:48All of the changes that we make to our repository

4:51are persisted under that Git directory here.

4:55So as you can see, if we just run LS by itself we don't see

4:59that .Git directory, and that helps us avoid accidentally

5:02making changes to it.

5:04So at this point, we do have a Git project here.

5:08And so I can actually run a Git log command,

5:10and you can see that the branch that I'm currently on,

5:13which is the master branch, does not have any commits yet.

5:18So we have not established a commit history,

5:20so we can't examine the history with the Git log command

5:24because we haven't made any changes to this project yet.

5:27All we have is what's known as a Git branch,

5:29and we'll talk about branches more in a separate skill that

5:33talks specifically about how branches work.

5:35But for now, when you initialize a new repository in Git,

5:38you automatically get a master branch with no commits on it.

5:43So let's go ahead and add some data into our Git project here.

5:47To do that, all you need to do is create a file.

5:51So you can do something as simple as a touch command,

5:53which literally will just create a file with a particular file

5:57name.

5:57So let's say that we're developing a bash script.

6:00So I'll say, touch script01.sh.

6:03And so if we do LS now, you can see

6:06that file has been created in our directory.

6:09And if we do an LS-L for long list format,

6:12you can see that file is 0 bytes in size

6:15because we haven't actually put anything into that file.

6:18It's just an empty file.

6:20So at this point, we could go ahead and create

6:22some additional files.

6:23We could say touch script02, touch script03.

6:27And so now we've got several different files

6:30inside of our Git project, but there's nothing inside of them.

6:33So typically, what you want to do

6:35is use a text editor like maybe Vim,

6:37for example, to make some changes to a file.

6:40So let's say Vim script04.sh.

6:43And down here, you'll see that Vim

6:45says that this is going to be a new file because we

6:47didn't create a script04.sh.

6:50But let's go ahead and just add in some text

6:53here into this file.

6:54So I'll do a shebang here and say, user bin env bash--

7:00and then we'll just say echo Hello.

7:04And then we'll do an escape and then

7:05we'll do a colon wq to save and quit Vim.

7:10And let's just do an LS-L. So now, sure enough, we

7:13have a fourth script file here.

7:15It's 32 bytes in size.

7:18And if we were to try to run that,

7:19we're actually going to get an error because we have not yet

7:22made that file executable.

7:23So I'm just going to do a chmod +x to make it executable,

7:27and we'll plug-in a script04.sh.

7:31And now if we do LS-L, should see

7:33that it has the execute bit enabled,

7:35and the colorization has changed to indicate

7:38that it's now executable.

7:39So we'll dot slash script04.Sn.

7:42And sure enough, our source code has run successfully,

7:45albeit being very, very simple in nature.

7:48So we have initialized a new Git repository,

7:50and we have our branch.

7:53Let me just do Git branch here.

7:55And we've got our master branch.

7:58And we don't have any commits yet.

8:00So in our next video, we'll go ahead and commit these changes

8:03to our Git repository, and then we'll

8:05start to see some history on our master branch

8:09because we'll have made some commits to that branch.

8:13I hope this has been informative for you,

8:15and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hi, guys, and welcome back.

0:12So in our last video, we initialized a new git

0:15repository, and then we created some files inside

0:18of that project.

0:19But we saw that we don't have any history in our git

0:22repository just yet.

0:24So if I run the git status command,

0:27which is another command that I recommended

0:30you refer to in the git sub-commands history here.

0:37What we can do is to run git status,

0:40and you'll see that git is telling us

0:43that there is a bunch of untracked files inside

0:47of our git repository.

0:48So we've got scrip01, 2, 3, 4.sh.

0:52And all of those files in red right

0:53here are considered untracked files

0:56as far as our git repository is concerned.

1:00And you'll see even right here it says No commits yet,

1:03and we're currently still on that master branch.

1:05We're not going to leave the master

1:07branch at this point in time.

1:08So it tells us right here how we can include these files

1:13into our git repository.

1:15And the way that we do that is by using this git add command.

1:20So you can specify git add and then one or more

1:23file names to add them to the working tree in the git

1:29repository.

1:30And then once they're in the working tree,

1:32then you can go ahead and actually commit them.

1:34You can commit those staged changes to the git index,

1:39and that will persist those changes into your git

1:42repository.

1:43So the only file that we've actually put any file contents

1:46into is script04.sh here, so that's the only one

1:50that I'm going to commit.

1:51Now you can commit empty files into a git project,

1:55but in general, there's not really much reason to do that.

1:59So I'm just going to do a git add on script04.sh here.

2:04And so now, if we rerun the git status command again,

2:07you're now going to see that under the staged changes

2:10right here, it says that it's going

2:12to add a new file into the git repository, which

2:16is script04.sh But the other files that we didn't add

2:21any contents to are still going to be considered

2:24untracked files even once we've made a commit to our git branch

2:30here.

2:30So now what we can do is commit these changes

2:33or commit this one change, I should say, this one new file

2:37into our project here.

2:39So we'll do git commit.

2:41And then typically, with a git commit,

2:43you're going to need to specify a commit message,

2:46and you're also going to need to specify your email address

2:50and your name as well.

2:53And that's the metadata that git uses

2:55to insert into the commit message

2:57so that you can see who made the change

2:59and what their email address is so you

3:02can get in touch with that developer

3:03and contact them in case you have

3:05an inquiry about the changes that they made.

3:09So you'll want to, as the git CLI recommends right here,

3:13you want to run the git config command here

3:15to configure your email.

3:17So we'll say trevor.sullivan@cbtnuggets.com.

3:22And then there's another attribute

3:23that we want to configure here called user.name as well.

3:27So you can just paste that in.

3:29And then I'll just say Trevor Sullivan

3:31and make sure that I have double quotes around that.

3:34And so now that's going to configure my name and email

3:37address from here on after, and the git CLI

3:41is going to use that in order to make additional commits

3:44in the future.

3:45So now we're going to run the git commit command.

3:48And if I don't specify any command line arguments,

3:51you're going to see that it opens up our default text

3:54editor.

3:54In this case, it's nano, and it's explicitly

3:57asking us to enter a commit message for your changes.

4:01So you actually do have to specify a commit message.

4:05So I'm just going to quit out of here, control-X to close nano,

4:09and you're going to see that it aborts

4:11the commit operation because we didn't

4:13specify a commit message.

4:15So what we typically do is use the --message parameter here.

4:20And this allows us to specify in quotes

4:22here a friendly message to the other developers

4:25on our development team so that we can inform them

4:28of what the changes are contained inside

4:31of this specific commit or snapshot of our source code

4:34changes.

4:35So I'll just say Adding new script with hello message.

4:42All right, and that's the only parameter

4:44that we have to specify on the commit command here.

4:47So as you can see under the summary of what

4:49was committed into our git repository here,

4:52only one file was changed.

4:55We added one new file into our project,

4:58and that file had three insertions, basically

5:01meaning three new lines that have been added

5:04into that particular file.

5:06And the name of that file is, of course, script04.sh.

5:11So git is very explicit with us.

5:14It's telling us what our commit message was.

5:16It's giving us the hash prefix for that particular commit.

5:20Git tracks everything as a hash so

5:23that you can see exactly when changes were made.

5:25And so this hash is going to change every single time

5:28that you make changes to different files,

5:30and you commit those changes into a repository.

5:33So it's showing us a summary of all the changes

5:36that were committed in the single commit to operation.

5:40So now that we've got a commit in our git history,

5:43we should be able to run the git log command.

5:45And sure enough, you can see that we have a commit.

5:48We can see the full hash of the commit.

5:51And then, we can see who made the change, when exactly

5:55that change was made, and we can also

5:57see a summary of what the changes were inside

6:00of that commit by seeing the commit message printed out

6:04right down here.

6:05So at this point, we might want to make some enhancements

6:08to that script file.

6:10So we could open that up in vim again.

6:12So open up vim script04.sh.

6:15And then I'll change this echo to say

6:19Hello World from CBT Nuggets!

6:23instead, and then we'll go ahead and save those changes

6:26with a colon wq in vim.

6:28And now, if we do a git status command again,

6:32now you're going to see that script04.sh no longer shows up

6:35under the untracked files section here.

6:38Instead, because the script04.sh file was already stored.

6:43It was already committed into the git index.

6:46We can now see that the status of that one file

6:50is now modified because the state of that file, something

6:54about that file, was changed between the last commit

6:57and the current state of that file that has not yet

7:02been committed.

7:03Now you'll notice that the change has not been staged

7:06for commit at this point.

7:08So if I try to run a git commit and say

7:13fixing, let's say --message equals

7:16Fixing hello message in script04,

7:21you can see that because this change was not

7:24staged for committing, the change was not

7:27actually made to that file.

7:29It says no changes were added to commit

7:32and so we actually have to use the git add command in order

7:35to stage that change first.

7:37So we'll say git add script04.sh.

7:41And you can oftentimes use tab completion

7:43if your shell has that built in for the file name there.

7:47And so now we're going to rerun a git status command.

7:50And now you can see that we have successfully staged

7:54that change, and so the next time that we

7:56make a commit the changes, the modifications to script04

8:00are going to get persisted into the git index.

8:04So now what we'll do is go ahead and do

8:06a git commit with that Fixing hello message

8:08in script04 message here.

8:10And now you can see that one file has been changed--

8:14not added-- because we've already

8:15committed that file before, but that file has now been changed,

8:18and one new line has been inserted into that file,

8:23and one line has been deleted from that file.

8:28So the old line was removed, the new line was added,

8:31and that shows how efficient git is with storing data

8:35because it's not creating an entire replica

8:37of the file with the changes.

8:40It's only recording the individual lines that actually

8:43have to be changed, and so git is

8:45very efficient from a storage perspective.

8:48It does not require a significant amount of storage

8:51to make changes to your simple plain text source code files.

8:55I hope this has been informative for you,

8:56and I'd like to thank you for viewing.

0:00[AUDIO LOGO]

0:11Hey, guys, and welcome back.

0:12So in the last video, we took a look

0:14at how to commit files into our Git repository

0:18and create this ongoing history or log of all the changes

0:23that we've made to our Git repository.

0:26So this is really helpful because the git log command

0:28is showing us a summary of the history of what

0:31changes have been made inside of our Git repository.

0:36Now, if this log gets longer and longer and longer,

0:40which inevitably it will, sometimes you're

0:43going to need to hone in on a specific file

0:46and look at the differences between one commit

0:50and another commit.

0:52So let's check out the git diff command,

0:54which is another command that I've

0:56put on my little quick reference here,

0:58and this is going to allow us to see

1:00unstaged changes in our working directory--

1:03so what's the difference between a previous commit

1:06and our current working directory--

1:09or we can actually use it to also see

1:11the difference between two different commits

1:14within our history.

1:15So let's check out the git diff command

1:17and how it's going to work here.

1:20So we can run git diff and then "dash dash help."

1:23That'll open up the help for this particular command

1:26in our terminal here, and as you can see,

1:30we are able to specify a commit hash

1:34that we want to use to examine our differences against.

1:39So, basically, it's going to take our current working

1:41directory and it's going to compare it to a commit

1:44that we point it to.

1:46Also, we can specify multiple commits

1:49if we want to examine the differences between two

1:53different commits, by specifying the hashes for each

1:56of those commits that are-- that we

1:58want to get the difference on.

2:00So at the moment, we just have two different commits

2:03in our history here.

2:04We simply made a new file, initially called script04.sh.

2:10And then we went into that file and we modified it,

2:13and we changed the text of that file.

2:15But remember, we only changed one line,

2:18but there's actually three lines in that file.

2:20So if we just cat script04.sh right here,

2:24you can see we've got three lines.

2:26We've got our shebang, an empty line,

2:28followed by the echo line here, and the echo line is the one

2:32that we changed between the first commit, with this hash,

2:35and the second commit, with this hash starting with 07f.

2:40So what we can do is use the git diff command to compare

2:45our current working directory, so let's run git status

2:48and just make sure that there's no pending changes, right?

2:51And so according to git status here,

2:54script04.sh has not been modified since the last commit,

2:59with 07f, so what I'm going to do is just do a git log.

3:04I'm going to copy this hash from our first commit

3:07to my clipboard, and then we're going to run a git diff

3:11and tell it to use that hash, that commit hash,

3:14to compare our current working directory,

3:17which matches the latest commit, with that very first commit

3:21that we had.

3:22So as you can see, it's going to print out

3:25the list of changes that were made

3:27to all of the different files that were changed

3:29between our current state and this commit starting with 568a.

3:34So as you can see, any file lines

3:38that have the minus sign in red here

3:41are going to be lines that were removed,

3:44and then the green text with the plus sign that is prefixing it

3:48are any lines that have been added to a particular file

3:52here.

3:52And it shows you a couple of lines of context

3:54around the lines that were changed, just so

3:57that you can get some context to understand

4:00exactly where that change was made in the file.

4:03It's also going to show us the summary of changes here.

4:07So you can see one line was deleted, one line was added,

4:11and we have a total of three lines in this file right here.

4:15And the file name, of course, is script04.sh.

4:20So as you can see, the git diff command

4:22is showing us the changes between this original commit

4:25and the latest commit that our current working

4:29directory matches.

4:30However, what would happen if we actually

4:32changed that file in our current working directory?

4:35So let's say that we added in another line

4:38here that does maybe an apt-get update and apt-get

4:42upgrade, which is just a very common command that

4:46is going to upgrade all of the installed packages

4:48on the Linux system here, very popular in DevOps scripts,

4:53and so now if we do a git status,

4:56you're going to see that we have a modified file that has not

5:00been staged for commit yet, right?

5:02We have not done a git add to stage that change for a future

5:06commit, but we can use the git diff command here.

5:09We're going to use the exact same command

5:11to compare with the very first commit in our project,

5:15but now you can see that we have five lines in our file

5:20rather than just three at this point,

5:23because we have added yet another line

5:26and another blank line here to our file.

5:29So what's happening here is that when we run the git diff

5:32command, it's actually comparing our current working directory--

5:36even though we haven't committed this new change where we've

5:39added these two new lines to our file,

5:41it's actually taking our current state of that file, not just

5:45the latest commit, and then it's comparing it

5:48with this historical commit, where we originally

5:51had the line just saying "echo hello" here.

5:54So any changes that even have not yet been committed

5:58are going to be shown by the git diff command,

6:01so this is useful for looking at any unstaged changes that

6:05have not yet been committed into your repository.

6:10And this'll give you a much better insight

6:12into what's going to be committed into your file

6:15when you do actually run a Git commit.

6:18So now I'll add yet another commit here.

6:21I'll say "git add script04.sh" right here,

6:26then we'll just do a git commit with a message saying

6:31"Adding apt-get commands."

6:34Cool.

6:35And so now if we take a look at our Git log,

6:37we should have three commits now, right?

6:39So now we've got this one starting with cc4,

6:42and so if we were to specify multiple commits,

6:45we could say, hey, Git, I want you

6:47to show me the differences between 568 and cc4, right?

6:51So what I can do is copy these commit hashes to my clipboard,

6:56and then we'll do a git diff command here.

6:59And then we'll paste in both of those different hashes here,

7:02and we do want to make sure we have the full hash.

7:04And now you can see that it's showing us

7:06a very similar output from before.

7:09But what we're doing in this case

7:11is we're specifying that we want to start at commit 568

7:14and go to commit cc4, right?

7:17And so what we could do instead of doing that is say,

7:19I want you to show me the differences between 07f

7:22and cc4, right, because I want to see only the changes between

7:26the last two commits here.

7:27And so instead of saying 568, I'll paste in the 07f right

7:31here, and now you're going to see that in this case,

7:35only the blank line with the apt-get command line has been

7:38added between the second-to-latest commit

7:42and the latest commits here.

7:44So I can look at any history here and say,

7:46I want you to show me, between this commit

7:49and this commit, somewhere in history,

7:50and Git is going to show us what changes were made

7:54between those different commits to different files inside

7:58of our Git repository.

7:59I hope this has been informative for you,

8:01and I'd like to thank you for viewing.