Understanding Git Commit

The process of saving your code's current state into Git is known as committing, and is executed using the git commit command.

In Git, commits represent an individual change to your project. These could be as small as fixing a typo, or as large as merging multiple branches. When you run the git commit command, Git creates a new commit object using the staged changes, attaches a unique identifier and a message reflecting what changes the commit introduces.

Let's look at a practical example:

git add example_filename
git commit -m "Add new example file"

Here, git add example_filename stages the changes made in a file called "example_filename". The changes are yet to be committed. The git commit -m "Add new example file" creates a new commit with the staged changes (from example_filename file), and assigns it a message "Add new example file".

As a best practice, your commit messages should be descriptive, reflecting the changes introduced by the commit. This makes it easier to understand the history of the project and to find specific changes later on.

Moreover, it's important to note that while the git add command is used to stage changes for commit, using the command does not save the changes in Git. They remain in a 'staged' state until committed with the git commit command.

Similarly, git stage is not a recognized Git command. It's a misleading option in this context. It's also worth mentioning that git init is used to initialize a new Git repository, not to create a new commit.

In conclusion, the key to saving the current state of your code into Git is to stage your changes with the git add command and then commit those changes with the git commit command. Each successive commit represents a new version of your project, allowing you to trace the history of changes and making collaboration smoother.