Until this point.
We know that git tracks two files in my repository, file one and file two, and it doesn't track the
whole temp directory and config text file because we excluded these files to be tracked with git with
the help of git ignore file in the previous lesson.
Now let me change these files by adding some content to it.
I'll type hostname command and redirect the output of this command to file one and I'll type who am
I?
Command and redirect this content, this output to the file to after making changes to these files and
saving them.
Let's see how git reacts by running git status command.
As you can see, it shows that certain changes have been made to two files.
We can also see exactly what was changed in the files, but running the following command git diff.
The diff command shows the changes that have been made to the direct files in the repository since the
last command.
In the output, we can see green lines starting with a plus sign.
It shows what's been added and the red line starting with a minus sign shows what's been removed.
When you add it a line of code, the same thing happens.
The old line is shown in red with a minus sign and the new version of the line is shown in green with
a plus sign.
If you want to check the changes in a single file, add the file name after the diff command.
For instance, git diff file one and keep in mind that git diff command shows the changes only interact
files.
Now, after you've reviewed the changes you made, you need to stage the changes to be committed by
typing git add file one.
File two.
Alternatively, you can add all tracked files like so git at dash you.
Now that you've staged the files, they are ready to be committed and you can type git commit dash.
Hm.
And I'll type in double quotes.
Added some info.
I must say that it's a good habit to review the changes that you've made with git diff command and try
to never stage files for commit before reviewing.
So up to this point we have more than one commit.
Let's explore a new area of git.
The history of the project.
The simplest way to review the history of a project is run in the following git log.
This command shows the commits that we've made so far.
The history shows the list of commits, each with a unique hash, an author, a timestamp and a commit
message.
This commit hash can be truncated.
Usually five, four six characters are enough to identify the commit in a repository.
For example, let me copy five first five characters of a commit and type git show and paste this truncated
hash and the git show command lists information about a commit.
So let's see how short we can go until git fails to identify the hash.
I'll type get show and paste first five characters.
Now let me truncate it up to four characters and git identifies it again.
And if I truncate it up to three characters, it will fail.