Now, we can try to make some modifications to the file and see how to deal with it, as shown in the following screenshot:

As you can see, the Bash shell warns us that there are some modifications painting the name of the modified files in red. Here, the git status command informs us that there is a file with some modifications, and that we need to commit it if we want to save this modification step in the repository history.

However, what does no changes added to commit mean? It is simple. Git makes you take a second look at what you want to include in the next commit. If you have touched two files but you want to commit only one, you can add only that one.

If you try to commit by skipping the add step, nothing will happen (see the following screenshot). We will analyze this behavior in depth in the next chapter.

So, let's add the file again for the purpose of getting things ready for the next commit:

Okay, let's make another commit, this time, avoiding the --message subcommand. Type git commit and hit the Enter key:

Fasten your seatbelts! You are now entering in a piece of code history!

What is that? It's Vim (Vi IMproved), an ancient and powerful text editor, used even today by millions of people. You can configure Git to use your own preferred editor, but if you don't do it, this is what you have to deal with. Vim is powerful, but for newcomers, it can be a pain to use. It has a strange way of dealing with text. To start typing, you have to press I for inserting text, as shown in the following screenshot:

Once you have typed your commit message, you can press Esc to get out of editing mode. Then, you can type the :w command to write changes and the :q command to quit. You can also type the command in pairs as :wq, as we do in this screenshot, or use the equivalent :x command:

After that, press Enter and another commit is done, as shown here:

Note that when you exit from Vim, Git automatically dispatches the commit, as you can see in the preceding screenshot.

Well done! Now, it's time to recap.