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 subcommand you want.
Now some of the major subcommands that you're going to use
with Git include things like the config subcommand.
This is used to set up options for a repository
or for your Git users, as well as other global options.
The init subcommand is used to create a Git repository
or re-initialize an existing one.
The clone subcommand is used to create a working copy
of an existing repository.
And the add subcommand is used to add files
to be tracked by the Git repository.
The commit subcommand 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 subcommand is going to be used
to display the status of the repository.
The branch subcommand is used to manage branches
or pointers to specific repository snapshots
after you've committed changes.
The merge subcommand is going to be used to integrate changes
from one branch into a master branch.
The pull subcommand is used to acquire and merge changes
that are made to other repositories and branches
into the local working copy.
The push subcommand is used to upload a local working copy
of a repository to a remote repository,
such as a centralized repository or database.
The log subcommand is used to display the changes made
to a local repository.
And the checkout subcommand is used to switch
to a specific branch that you want to work with.
The tag subcommand is going to be used to add a tag
to your Git repository,
which acts as a specific reference point
in your Git history.
These git tags are used to capture the specific point
in history that is further used to point
to a released version.
Now, this tag doesn't really change a branch,
but instead it just adds a marker
for us to be able to realize what happened
at that given point in time.
The rebase subcommand is one of two Git utilities
that specializes in integrating changes
from one branch into another.
The other one is the merge command.
Now, when we talk about the merge command,
it's always about making a forward-moving change record
that's going to merge both bases into one,
and that's going to become the one
we're going to use moving forward.
But with rebase, we instead are going to use this
to do a rewriting of our historical features.
For example, when we rebase, this is really the process
of moving or combining a sequence of commits
to a new base commit.
Now the primary reason for rebasing is
to maintain a linear project history.
And this allows you to re-baseline
into a new baseline history moving forward.
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 dash dash global user.name
quote User quote,
where user's the name of the user you want to create.
Second, you're going to create a directory
where your project's 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 subcommand.
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 quote, initial commit or whatever message I want,
end quote.
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 changed 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, and 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 developers' 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 dash dash since equals 10 dot 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 git ignore file.
This is written as dot 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 read me dot TXT file,
or a project to do dot 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 git ignore file, those will get ignored
when you do a commit.
Another thing that's important is the star dot git slash.
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, for Linux Plus, you're not going to need
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 have to be an expert
on it for the exam.