Creating Your First Commit: Saving Progress in Git

Previously in this course, we covered Initializing a Repository and explored the Understanding the Git Lifecycle to move files into the staging area using Tracking Files. Now that your changes are staged and ready, this lesson teaches you how to finalize that work by creating a permanent snapshot of your project.

What is a Git Commit?

In Git, a commit is a permanent record of your project at a specific point in time. Think of it as a "save point" in a video game. Once you create a commit, you can always return to that exact state of your files, even if you make disastrous changes later.

A commit isn't just a copy of your files; it is a cryptographic snapshot of the entire project state, accompanied by metadata: who made the change, when they made it, and a message explaining why the change was made. Building a clean, readable version history relies entirely on your ability to make logical, focused commits.

The Anatomy of git commit

When you run git commit, you tell Git to take everything currently in the staging area and permanently record it in your repository's history.

The Worked Example

Let’s advance our running project. Assume we have a file named README.md that we have already added to the staging area. To commit this change, we use the -m flag to provide a descriptive message directly in the terminal:

Bash
# Verify your files are staged
git status

# Create the commit
git commit -m "Initialize project documentation"

When you hit enter, Git will output something like this: [main (root-commit) a1b2c3d] Initialize project documentation 1 file changed, 1 insertion(+) create mode 100644 README.md

• The Hash: a1b2c3d is the unique ID for this specific snapshot.
• The Message: "Initialize project documentation" is your log entry.
• The Change: It confirms exactly what happened (1 file created).

Writing Effective Commit Messages

A commit message is a letter to your future self and your teammates. Avoid generic messages like "update" or "fixed stuff." Instead, follow these basic conventions:

1. Be Imperative: Write your message as a command (e.g., "Add login feature" instead of "Added login feature").
2. Be Concise: Keep the subject line under 50 characters.
3. Be Descriptive: If the change is complex, use a blank line after the subject and add a body paragraph to explain the why behind the change.

Hands-on Exercise

1. Open your project directory in your terminal.
2. Create a new file called todo.txt and add a line of text to it.
3. Stage the file using git add todo.txt.
4. Commit the file with a clear, imperative message: git commit -m "Add initial task list".
5. Run git status to confirm that your working directory is clean.

Common Pitfalls

• Forgetting to Stage: Running git commit without running git add first will result in "nothing to commit." Always check git status if you aren't sure what is ready to be saved.
• Vague Messages: If you find yourself typing "fixed bug" as a commit message, stop. Describe which bug you fixed. Future-you will appreciate the clarity when searching through logs to find when a regression was introduced.
• Committing Too Much: A commit should ideally represent a single logical unit of work. Don't mix unrelated changes (like fixing a typo and adding a new feature) in a single commit.

Frequently Asked Questions

Q: What happens if I forget the -m flag? A: Git will open your default text editor (usually Vim or Nano) to allow you to write a longer, multi-line commit message. If you aren't comfortable in these editors yet, always use -m.

Q: Can I change a commit message after I've made it? A: Yes, but we will cover that in more advanced lessons regarding history manipulation, such as those discussed in Git Interactive Rebase. For now, focus on getting the message right the first time.

Q: Does a commit include untracked files? A: No. Git only commits files that are currently in the staging area.

Recap

You have now learned that a git commit serves as a permanent snapshot of your project state. By using git add to stage changes and git commit to save them, you are effectively building the version history of your project. Keep your commits small, logical, and your messages descriptive to ensure your repository remains maintainable.

Up next: We will look at how to review the history we’ve just started creating using git log.