In this lesson,
we're going to discuss Git and its core commands.
Now most of the time when developers collaborate
for a certain project,
they need to have a distributed version control system
so they can easily manage
the different versions of the code they're writing
and minimize any conflicts while being able to revert back
to older versions of the code
if they make any kind of mistake.
In this case,
you're going to be able to use something like Git.
Now let's say you just arrived from your vacation
and you wanted to check on the progress
that your team has made on a project
that you were working on.
Well, if you had a version control system,
you could very easily do this by knowing what version it was
or what date it was last controlled or changed.
Now by far, the most commonly used
modern version control system in the world
is known as Git, G-I-T.
Now Git is a mature, actively maintained open-source project
that was originally developed back in 2005
by the same person who developed the Linux operating system.
Now a staggering number of software projects
rely on Git for version control,
including a lot of commercial projects
as well as most of the open-source community.
Its core component of Git is known as the Git repository.
This is a storage area where versions of code
and related files are going to be put.
To get started with Git,
you can use an available package manager
to install the Git package.
To run the Git command,
simply type in git, the options,
and the sub command you want.
Now some of the major sub commands
that you're going to use with Git
include things like the config sub command,
this is used as set up options for repository
or for your Git users, as well as other global options;
the init sub command is used to create a Git repository
or reinitialize an existing one;
the clone sub command is used to create a working copy
of an existing repository;
and the add sub command is used to add files
to be tracked by the Git repository;
the commit sub command is going to be used
to update the Git repository with your changes
and this essentially creates a snapshot of that repository
or a snapshot of the files
at that particular moment in time;
now the status sub command is going to be used
to display the status of the repository;
the branch sub command is used to manage branches
or pointers to specific repository snapshots
after you've committed changes;
the merge sub command is going to be used
to integrate changes from one branch into a master branch;
the pull sub command is used
to acquire and merge changes
that are made to other repositories and branches
into the local working copy;
the push sub command is used to upload
a local working copy of a repository
to a remote repository,
such as a centralized repository or database;
the log sub command is used to display the changes
made to a local repository;
and the checkout sub command
is used to switch to a specific branch
that you want to work with.
All right, let's say you need to create a local repository
and commit some changes to it as you go through the process.
Well, let's talk about the process flow for doing this.
First, you're going to configure global settings
including the username by typing
git config --global user.name 'User',
where users the name of the user you want create.
Second, you're going to create a directory
where your project is going to reside.
To do this, you're going to type in mkdir /dev-project,
and then we're going to change ourself into that directory
by using the cd command.
Now we want to initialize this directory using Git
to make it a Git repository.
So we'll do this by typing git init /dev-project.
Now at this point we want to put some project files
into this repository.
These are going to be the files
that make up the actual development project
that we're storing and controlling using Git.
In Git, you create a working copy
by using the clone sub command.
So we're going to type in git clone /dev-project.
Next, we're going to type Git add myfile
and this will add the project files
into the Git tracking system, specifically myfile.
Next, we want to be able to commit the changes
by taking a snapshot of our project.
So at this stage,
we're going to enter a message that summarizes
what changes we made.
For example, I might type in git commit -m,
and then 'Initial commit,
or whatever message I want'.
Now at this point,
if we want to see the status of our Git repository,
we can type in git status
and this will retrieve the current status
of the change files.
So if I had three files that were being worked on
for a particular step in this project
but only two were ready to be committed at this time,
those would show up here as added but not yet committed.
Another option here is to work with Git branches.
Now branching is a feature
in most modern version control systems.
In Git, branches are part
of your everyday development process,
and Git branches are effectively a pointer to a snapshot
of your different changes you've made.
When you want to add a new feature or a fix or a bug,
no matter how big or small, you're going to spawn a new branch
to encapsulate your changes.
By creating a branch in the master copy of the code,
you're going to be able to then work on that
without affecting all the other developers.
To do this, you're going to type git branch,
and then the name of the new branch that you want.
Then whenever you're done
and you need to merge those changes
back into the master branch,
you're going to type git merge,
and the name of that new branch.
This will be able to make those changes
and put them back into the master branch.
In doing so, allows you to create new and improved versions
of the software and the master branch.
Now this is one of the reasons that Git
is so powerful is this ability to create branches
and then put them back and commit them
into the main master branch.
This allows Git to be very collaborative
and it really becomes game changing for software developers.
So, so far we've been collaborating
with our most important collaborator, right?
We've been working with ourself,
but Git allows us to collaborate with somebody else
or with lots of other people as well
as long as they're also going to have the same privileges
to our Git repository.
Normally, there's going to be some sort of a process flow
when you're collaborating with other developers using Git,
and you're going to work that out
based on your organizational requirements.
For example, a standard way of doing this
might be to first type git pull,
and then pull in the other branch
to pull the other developer's code and changes
and merge them into your local repository.
Then you might type git push,
and the remote repository with your branch
to push your own changes back to that remote repository.
This allows developers all over the world
to pull and push changes into the central repository
so they can all work together.
Now any changes made locally are then going to be uploaded
to that central repository using that push command,
and you can see what changes were merged
and what other actions were taken on that repository.
Again, if you want to be able to see
what's inside your project directory,
you can type git log
and that's going to be able to tell you all the changes
that have happened over a certain period of time.
For example, if I enter git log --since=10.days,
I'm going to see all the commits that have happened
in the last 10 days.
I can use this information to troubleshoot any issues
that may have come up in the last 10 days
or anything I might have missed
if I was on vacation for the last 10 days.
Another thing you can do
is you can navigate and switch between branches of a project
by using the checkout command inside of Git.
To do this, you'll type git checkout
and the specific branch you want to check out.
This enables developers
to focus their attention on different branches
of the same project
and really hone in on what they're working on.
Now another thing that we need to talk about
is this file known as the gitignore file.
This is written as .gitignore,
and it's a file that exists within the repository.
The purpose of this file is to identify files
that should be ignored during a commit action.
For example, you might have a README.txt file
or a project todo.txt list that's inside this directory
and you don't need that to be committed
as part of the project,
but it does reside inside your project directory
just for your convenience.
Well, if you're going to use those
and you list them out inside the gitignore file,
those will Git ignored when you do a commit.
Another thing that's important is the *.git/.
This is a directory that contains all the files
that Git is going to use
to manage version control for your project.
It's going to be a single location
where Git stores all of its information.
Think about it like almost like a flat database.
The directory here resides in the project directory
and it's created with the git init command
at the beginning of your project.
So as you can see, there is a lot to know inside of Git,
but the good news
is you're not going to know it fully in depth.
Git is something used heavily by software developers
and not nearly as much by system administrators.
It's something you should know about,
but you're not going to be an expert on it for the exam.