Committing Changes (git commit)

Once you have carefully selected the changes you want to include in the next project snapshot using git add (placing them into the staging area), the next step is to permanently store that snapshot in your repository's history. This is accomplished with the git commit command. Think of a commit as saving your progress in a game; it creates a safe point you can return to later. Each commit represents a version of your project at a specific point in time.

Saving Your Staged Changes

The fundamental command is simply:

git commit

When you run this command without any additional options, Git will open the text editor you configured during setup (or a default editor like Vim or Nano). This editor prompts you to enter a commit message.

The Significance of Commit Messages

The commit message is a description of the changes you've made in this specific commit. It's a note to your future self and collaborators explaining why these changes were made. While we'll cover writing effective messages in the next section, the basic structure typically involves:

1. A short, descriptive summary line (usually 50 characters or less).
2. A blank line.
3. A more detailed explanation, if necessary, providing context, motivation, or implementation details.

After you write your message, save the file and close the editor. Git will then create the commit, incorporating the changes currently in the staging area.

The -m Shortcut

For simpler changes where a short summary line is sufficient, you can bypass the text editor by providing the message directly on the command line using the -m flag:

git commit -m "Add initial project structure with README"

This command performs the commit immediately using the provided string as the message. This is convenient for small, straightforward changes, but for more complex updates, taking the time to write a detailed message in the editor is often better practice.

What Happens Under the Hood?

When you execute git commit, Git performs several actions:

1. It takes the files exactly as they are represented in the staging area (index).
2. It creates a new commit object. This object contains:
   • A reference to the snapshot of your project's content (specifically, the tree object representing the project's root directory).
   • Metadata: The author's name and email (from your configuration), the timestamp, and your commit message.
   • A reference (or references) to the commit(s) that came immediately before this one. These are called the parent commits. Most commits have one parent, representing a linear history. Merge commits, which we'll see later, have multiple parents.
3. It calculates a unique 40-character SHA-1 checksum (hash) for this commit object. This hash acts as the commit's unique identifier.
4. It updates the current branch (e.g., main) to point to this newly created commit.

This process ensures that each commit is a complete, identifiable snapshot of your project, linked chronologically to previous versions.

The git commit command creates a new commit object (e.g., 9e1d5) using the staged changes. The HEAD reference, which indicates your current position, along with the branch pointer (main), moves forward to point to this new commit.

Example Workflow

Let's walk through a typical sequence:

1. Modify a file: Edit your README.md file.
2. Check status: Run git status. Git will report that README.md is modified but not staged.

   $ git status
   On branch main
   Changes not staged for commit:
     (use "git add <file>..." to update what will be committed)
     (use "git restore <file>..." to discard changes in working directory)
           modified:   README.md
   
   no changes added to commit (use "git add" and/or "git commit -a")
   

3. Stage the file: Run git add README.md.
4. Check status again: Run git status. Git now shows the file is staged and ready for commit.

   $ git status
   On branch main
   Changes to be committed:
     (use "git restore --staged <file>..." to unstage)
           modified:   README.md
   

5. Commit the changes: Run git commit -m "Update README with project description".

   $ git commit -m "Update README with project description"
   [main 9e1d5f0] Update README with project description
    1 file changed, 2 insertions(+)
   

6. Final status check: Run git status. Git now reports a clean working directory, indicating that all tracked changes have been committed.

   $ git status
   On branch main
   nothing to commit, working tree clean
   

You have successfully recorded a snapshot of your project! The commit, identified by its unique SHA-1 hash (like 9e1d5f0 in the example output, though yours will differ), is now part of your project's history. You can view this history using the git log command, which we will explore soon.

Remember, git commit only records the changes that have been staged using git add. Any modifications you made to files in your working directory after the last git add will not be included in the commit unless you stage them first. This two-step process (staging then committing) gives you precise control over exactly what goes into each snapshot of your project history.