Exercise 1.6: Stage and commit changes with Git

Author

Chuck Nelson

Published

September 22, 2025

1 Stage and commit changes with Git

What is Staging?

The staging area (also known as the “index”) is an intermediate area in Git where you prepare changes before committing them. Think of it as a “draft” area for your next commit. When you make changes to files in your working directory, Git sees them as “modified.” To include these modified files in your next commit, you must first add them to the staging area. This allows you to selectively choose which changes go into a commit, making your commits more focused and meaningful.

What is a commit?

A commit is a snapshot of your repository at a specific point in time. When you make a commit, Git records the current state of your staged changes, along with a message describing what changes were made. Each commit has a unique identifier (a SHA-1 hash) and forms part of the project’s history. Commits are fundamental to Git, allowing you to track changes, revert to previous versions, and collaborate effectively.

Using conventional commit messages

Conventional Commits provide a standardized format for commit messages. This makes it easier to understand the purpose of a commit at a glance, automate changelog generation, and enforce consistent commit history. A typical conventional commit message looks like this:

<type>(<scope>): <description>

[optional body]

[optional footer(s)]
  • type: Describes the kind of change (e.g., feat for a new feature, fix for a bug fix, docs for documentation, style for formatting, refactor for code refactoring, test for adding tests).
  • scope (optional): Specifies the part of the codebase affected (e.g., auth, ui, README).
  • description: A concise summary of the change.
  • body (optional): A more detailed explanation of the change.
  • footer(s) (optional): Can include references to issues (e.g., Closes #123) or breaking changes.

Example: feat(README): Add Javadoc link

1.1 Prerequisites

  • You have the hello-world Java project open in VS Code.
  • Your have made the code changes in the previous exercises.
  • You code compiles and passes tests.

1.2 Commit changes to source control

Finally, you will commit all your changes and get them ready to push to your remote GitHub repository. Here are the steps you will take.

  1. In the VS Code Source Control view, you should see the README.md, index.html, and .gitignore files listed as changes.
  2. Stage all three files for commit.
  3. Write a clear commit message, such as “Feat: Add Javadoc link to README”.
  4. Commit the changes.

Stage your changes

To stage your changes, you are telling Git which modifications you want to include in your next commit.

To stage all modified files:

git add .

To stage a specific file (e.g., README.md):

git add README.md
  1. Open the Source Control view (Ctrl+Shift+G or click the Git icon in the Activity Bar).
  2. In the “Changes” section, hover over the file you want to stage.
  3. Click the + icon (Stage Changes) next to the file name.
  4. To stage all changes, click the + icon next to the “Changes” heading.

Commit your changes

Once your changes are staged, you can commit them. This creates a permanent snapshot of your project’s state.

To commit staged changes with a message:

git commit -m "Feat: Add Javadoc link to README"

If your commit message is longer or requires multiple lines, you can omit the -m flag, and Git will open your default text editor:

git commit
  1. Open the Source Control view.
  2. Ensure your desired changes are in the “Staged Changes” section.
  3. Type your commit message into the message box at the top of the Source Control view.
  4. Click the Commit button (the checkmark icon) or press Ctrl+Enter.

Your code changes are now ready to be synchronized with a remote repository.

See Git Workflow and Project Management for more in-depth discussion on using Git and GitHub.

Back to top