Skip to main content
Welcome to this practical demonstration that complements the lecture content. In this guide, you will learn about the different states a file can have in your Git working directory and how to transition files between these states using Git commands. We start by creating a new file named story_one.txt in an existing Git repository within the story_blog directory. This file will include sample content to illustrate the process. Below is an example of initializing a Git repository and verifying its structure:
When a new file is created for the first time, Git considers it “untracked.” Once you decide the file is ready to be permanently saved (committed), you add it to the staging area. For instance, after creating a file named story1.txt with some content, check its status:
At this stage, the file is in the staging area. Before proceeding with a commit, ensure that Git is configured with your username and email. This information will be recorded as the author for the commit:
To commit the staged changes, run:
After entering your commit message in the default text editor, Git creates the commit. The output will look similar to this:
A commit saves a snapshot of your file’s current state in the .git folder. This snapshot allows you to safely restore previous versions of the file even if modifications or corruption occur later. After a successful commit, your working area will be clean:

​
Modifying a Tracked File

If you modify a file after committing, its state changes to modified (unstaged). For example, let’s add a new line to story1.txt:
If the changes are unintentional, restore the file to its previously staged version:
When you intentionally update the file, add it to the staging area, then commit the changes. You can include the commit message directly using the -m flag:
With this commit, Git archives the current version of the file, preserving its history for future reference.

​
Committing Multiple Changes

Consider a scenario where you update story1.txt and create a new file named story2.txt:
If both changes are related, you can stage them together:
It is best practice to commit unrelated changes separately. Keeping commits atomic makes it easier to understand your project’s history and revert changes as necessary. For example, if one commit contains both a front page addition and an unrelated bug fix, it can be difficult to isolate one change without affecting the other.
The following diagram illustrates the contrast between good and bad commit practices:
The image shows a comparison of two Git commit histories, highlighting changes made by different users with corresponding avatars.
A good commit history keeps each commit focused on a single change. In contrast, mixing unrelated changes into a single commit creates confusion. The diagram below further compares “bad” and “good” Git commit messages:
The image compares "bad" and "good" Git commit messages, showing improvements in clarity and specificity for each commit.

​
Handling Modifications on a Staged File

Imagine you add a new line (line4) to story1.txt:
If you accidentally overwrite its contents after staging, Git will indicate that the file is both staged and modified:
Since Git retains the staged version, you can restore it with:

​
Committing Specific Files

Now consider a scenario with two files in different modification states. Suppose story1.txt is staged while story2.txt is modified:
To commit story2.txt separately without including the staged changes from story1.txt, first remove story1.txt from the staging area:
Then add and commit story2.txt:
At this point, story1.txt remains modified and can be committed later with its own commit message.

​
Managing Untracked Personal Files

Sometimes you may have personal files that should not be tracked by Git, such as a file named notes.txt for your personal ideas:
If you stage all changes with git add ., notes.txt will also be staged along with story1.txt:
Since notes.txt is a personal file that you do not want to commit, remove it from the staging area using the cached option:
To permanently prevent accidental staging of personal or sensitive files like notes.txt, add the filename to your .gitignore file:
Add notes.txt to your .gitignore:
Including a .gitignore file in your repository is a best practice—it clearly communicates to your team which files or directories (such as logs, caches, or build artifacts) should be ignored by Git.

​
Conclusion

This demonstration covers how to:
  • Initialize a Git repository.
  • Track, stage, and commit new and modified files.
  • Handle scenarios where only specific files should be committed.
  • Maintain a clean working directory with best practices like atomic commits and proper use of .gitignore.
Head over to the labs and practice these commands to reinforce your understanding of Git file states and commit best practices. Happy coding!

Watch Video

Practice Lab