Git does not automatically save every change you make. You must tell Git which changes you want to be recorded by staging those changes. After staging, you can then commit the changes so that they are recorded in the repo.
As mentioned in the Git workflow section, the working tree is where you make changes. There you can edit files, add new files, and remove files that are no longer needed.
Once a file has been changed in the working tree, it is noted as modified in the index (e.g., the staging area where new commits are prepared) where it sits between the repository and the working tree.
Changes made in the working tree are not saved directly to the repository. All changes are first staged in the index and then saved in the repo. Only the files in the index are committed to the repo.
The git commit command lets you record file changes in the repository's Git history.
Every change you commit will be viewable in the respective file or directory in chronological order.
A 40-character checksum hash uniquely identifies each commit. You can use the checksum hash to retrieve the status or changes that were made on the given commit in your repository.
Separating different types of changes such as bug fixes, new features, and improvements into different sets of commits will allow you and your team members to understand why and how those changes were made easily.
When committing your changes, you are required to enter a commit message. The commit message should accurately describe the changes you're making.
Make commit messages easy to understand for all your team members. We recommending trying the following structure:
1st line: Abstract of the contents changed by commits
2nd line: Blank line
3rd line and the following lines: Reason for changes