In this lesson, we'll look at how to stage and commit changes with git.
Now there are three steps to modifying code and then tracking changes with git,
make changes in the working area,
add the changes we want to track with git to the staging area
and then committing our changes
at this point. The first step is done
because the working area is the project directory that we're currently in
and we already made our changes to the working area when
we added our two files and the text inside them.
So every time we change something in our project's directory,
we've modified our working area
and now we get to phase two, the staging area.
This is how we tell git about the changes that we made to our
project or more specifically what changes we want to track in the next commit.
We might wonder why doesn't git just check the
working area and track all the changes automatically?
Why do we have to add these changes to the staging area?
Well, one answer is that git can't know when we finish making our changes.
For example,
maybe we added 50 lines of code today in some file,
but we intend to add another 50 lines tomorrow to wrap things up.
So we don't want git to track this partial change when we're at 50% progress.
We want to wait until we finish adding all our lines of code.
Also, if we modify 10 different files,
we don't want it to track 10 different phases for each file.
Instead, we want to track this as a single change.
Even if we modified 10 files,
maybe this was just done to add a new feature to our software project.
So we want to track this all as a single modification in our project's life cycle,
not 10 separate modifications.
Now, let's go back to our demo and see how this works.
OK? We're back to our prompt here
with two files in our project.
It's easy to know what we changed and what we want to stage.
But what if our project is very complex?
Imagine we added a new feature and we had to modify 16 files.
We might forget what files we changed in the last few hours.
However, git has a command that can show us exactly what we modified.
This command is git status.
Now, we begin to see the awesome power behind git.
It already noticed what changed and it even shows us the next command that
we have to use to add these two files to the staging area.
We'll type, get
a
file one
file two.
Now let's check the git status. Again,
we can see that git is prepared for the third step that is committing changes.
So basically file one and file two are now in the staging area.
We told git that these are changed files that we want to track.
But nothing will be tracked until we actually commit this staging area to git.
Staging something in git is like pointing your phone's camera at something
you frame the image you want to capture but nothing is captured yet.
However, when you click the camera button, a
picture is taken and stored in your phone's memory.
Git does the same thing. When you commit to the staging area,
it takes a picture of how these staged files looked at a certain point in time
in the status above. We can also see how to unstage a file from git.
But it's not recommended to use the git
RM command as it can have unintended consequences.
If we forget to add the dash dash cached
parameter,
we might accidentally remove the file from the project entirely
instead of just removing it from the staging area.
So to unstage a file, we can run a command like this,
get reset file two,
but in this case, everything looks good. So we will not execute this command.
It's just a reminder that we have this option if we ever need it.
It's also worth mentioning that some projects are quite complex
and we'd waste a ton of time manually typing the names of tens or hundreds of files.
So we can use some shortcuts to stage multiple files. Here are a few examples
to add only the files that have the HTML extension in the current directory.
We can type something like this
and it's important to use the quotes in this case to prevent our bash
shell from expanding the star asterisk character
and lead to some unexpected results.
Also git can stage entire subdirectories.
For example,
imagine we wanted to add a subdirectory called products in our current directory.
To tell git to add that to the staging area. We could use something like this,
get
a
product slash,
all the files and subdirectories within that directory would be staged as well.
And to add only the files with the HTML extension from the product subdirectory,
we would run this,
we're using the asterisk character again. So we need to use the quotes as well.
For the reason we mentioned earlier,
make a mental note to remember to always
use quotes when you use the asterisk character.
Now, of course,
we can also use the same tricks to remove
multiple files at once from the staging area.
So a command like this git reset product start out HTML is also valid.
Now,
we can get to the third and final phase of
tracking changes with the help of git committing changes.
Remember that many team members are possibly working on your project's code.
So we want to help them out. When they're looking at the changes that we made
for this purpose. It's standard practice to add a comment for each commit.
In this comment, we briefly explain why we made the changes
to add a comment to a commit. We use the dash M command option
and dash m is short for message.
So we'll run this command to commit our changes to file one and file two.
Now, as you can see, we needed to add the message between quotes.
Otherwise our bash shell would be confused
instead of the multiple words separated by spaces.
It would think that we have multiple command-line arguments for the dash M option.
So wrapping our message between quotes tells bash
that this is a single command-line argument.
So what does git do when committing changes?
It takes a look at what we added to our staging area.
And as we mentioned before, it makes sort of a snapshot
this way,
it understands what changed between the last time the project was modified.
And this time
it's what makes stuff like this possible.
This is an example from the github
page for the Linux kernel after a git commit was made
in a local repository and then uploaded to this remote repository.
Now, other people can see exactly what changed
and we see a list of files that were modified,
how many lines were added and how many were deleted.
And we can also notice that the change lines are highlighted,
red highlights show what was removed or the old content
and the green highlight shows us what was added or the new content.
This makes it easy for other team members to check out the latest code changes.
Now in our case,
git will notice that our project went from an empty project directory
to a project directory with two files containing lines of text.
So as a reminder, tracking changes with git consists of three main steps,
we make changes to our working area,
which is simply the directory where we store our project locally.
Step two,
we tell git about the changes we want to track
by adding files and directories to the staging area.
And in step three, when we prepared everything,
we tell git to commit all of these changes that we've added to the staging area.
In other words,
we tell it to track this exact state of the project so that
it can remember all the states or commits that this project went through.
It's worth mentioning that we've covered just one type of changes to a project,
adding new files, but there are other types of changes as well.
For example, sometimes a project can simply have unnecessary files deleted.
Let's go through this scenario too.
First, we'll create a third file with this text
and we'll add it to the staging area.
Next, we'll commit this with a change to getit.
Now, at this point,
we can imagine noticing that this feature is buggy and it isn't worth fixing it.
So we decided to just remove it from the project entirely.
Now, if we look at the current state of the project,
we see that we have three files to tell git to remove this file from the project,
we can use this command,
get RM file three.
This does two things.
It removes the file from the repository or the so called working area.
And we can see this confirmed if we list our current directory.
But the git RM command also stages this change for the future commit.
So it stages the removal of this file from the project
and we can see this with git status
and this change is ready to be accepted.
So let's commit it with this command.
Now, we saw two types of changes that we can track with git,
adding new files and removing files from the project.
There's also another type of change, modifying old files,
which simply means that git can track what lines of code we change in our files.
And this gives us the opportunity to check out another git feature branches
and I'll see you in the next lesson.