When learning Python, you will work with different types of data, such as numbers, text, decimal values, and Boolean values. Python provides several built-in functions to help you work with these data types. One of the most useful functions is the type() function . The type() function tells you the data type of a value or variable. It helps you understand what kind of data Python is working with and can make debugging your programs easier. For example, consider these variables: age = 20 price = 99.50 name = "Rahul" is_student = True Although all four variables store data, their data types are different. Python allows us to check these types using type() . Let's understand how it works with simple examples. 1. What Is the type() Function in Python? The type() function is a built-in Python function that returns information about the type of an object. In beginner-level programming, you can use it to check whether a value is an integer, a floating-point number, a string,...
In the previous article, you learned about the Git Lifecycle, which consists of the Working Directory, Staging Area, and Local Repository.
Now it's time to explore one of Git's most important concepts in greater depth—the state of a file.
Every file in a Git repository is always in one of several states. Understanding these states is essential because Git commands such as git add, git commit, and git status simply move files from one state to another.
Many beginners memorize Git commands without understanding what happens internally. Professional developers, however, understand the state transitions behind every command.
In this article, you will learn:
What file states are
How Git tracks files
Every file state in detail
How files move between states
Real-world examples
Common beginner mistakes
Best practices
By the end of this article, you'll be able to predict exactly what Git is doing whenever you run a command.
What is a File State in Git?
A file state describes Git's current knowledge about a file.
For example:
Has Git ever seen this file?
Has the file changed?
Is the file ready to be committed?
Has the file already been saved in the repository?
Git answers these questions by assigning a specific state to every file.
The Five Main File States
A file in Git can be in one of the following states:
New File
│
▼
Untracked
│
git add
▼
Tracked
│
Modify File
▼
Modified
│
git add
▼
Staged
│
git commit
▼
Committed
This cycle repeats throughout the life of the project.
State 1: Untracked
An Untracked file is a file that Git has never tracked before.
Example:
You create:
Student.java
Git notices that the file exists, but it is not part of the repository yet.
Git says:
"I see this file, but I am not tracking it."
Real-Life Example
Imagine joining a library.
A new book arrives.
Until the librarian records it in the library database, the book is unregistered.
An untracked file is exactly like that new book.
Characteristics of an Untracked File
Newly created
Not included in commits
Git does not track changes yet
Must be added before it becomes part of the repository
State 2: Tracked
Once Git begins monitoring a file, it becomes Tracked.
Tracked means:
Git knows this file and will monitor every future change.
After a file is tracked:
Editing it
Renaming it
Deleting it
will all be detected by Git.
Example
Suppose you create:
Main.java
After adding it to Git, the file becomes tracked.
Now every future modification will be recorded by Git.
State 3: Modified
A tracked file becomes Modified whenever its contents change.
Suppose your file contains:
public class Main {
public static void main(String[] args) {
System.out.println("Hello");
}
}
Later you edit it:
public class Main {
public static void main(String[] args) {
System.out.println("Hello Git");
}
}
Git immediately notices the difference.
The file is now Modified.
What Does Modified Mean?
Modified means:
"This file is different from the last committed version."
The changes exist only in the Working Directory.
They have not yet been prepared for the next commit.
State 4: Staged
A modified file becomes Staged after you tell Git:
"Include this file in my next commit."
The Staging Area acts like a waiting room.
Files remain here until a commit is created.
Real-Life Example
Imagine you are ordering food.
Food prepared in the kitchen is not served immediately.
It waits on the serving counter until everything is ready.
The serving counter is like the Staging Area.
Characteristics of a Staged File
Ready for commit
Stored temporarily
Can still be modified again
Not yet part of project history
State 5: Committed
Once you create a commit, Git permanently stores the staged files in the repository.
This creates a new snapshot of the project.
Now the files become part of Git history.
Real-Life Example
Think of taking a photograph.
Before clicking the camera button, people can move around.
Once the picture is taken, that moment becomes permanent.
A Git commit works the same way.
Complete File State Journey
Suppose you create a Java application.
Step 1
Create:
Calculator.java
State:
Untracked
Step 2
Tell Git to track it.
State:
Tracked
Step 3
Edit the file.
State:
Modified
Step 4
Prepare it for saving.
State:
Staged
Step 5
Save permanently.
State:
Committed
Step 6
Edit the file again.
State:
Modified
The cycle starts again.
Visual Representation
Create File
│
▼
Untracked
│
Start Tracking
│
▼
Tracked
│
Edit File
│
▼
Modified
│
Prepare Changes
│
▼
Staged
│
Save Snapshot
│
▼
Committed
│
Edit Again
│
▼
Modified
This process repeats for every project.
How Git Knows a File Has Changed
Git compares the current version of the file with the version stored in the latest commit.
If they are different:
Committed Version
│
Compare
│
Current Version
Git marks the file as Modified.
Git does not compare filenames only.
It compares the actual content.
Why Doesn't Git Automatically Commit Everything?
Imagine editing ten files.
Only six are complete.
The remaining four still contain bugs.
If Git committed everything automatically, incomplete work would become part of project history.
Instead, Git allows you to choose exactly which files should be committed.
This is why the Staging Area exists.
Common Beginner Mistakes
Mistake 1
Thinking a saved file is automatically committed.
Saving a file only updates the Working Directory.
Git commits only when instructed.
Mistake 2
Assuming tracked means committed.
Tracked simply means Git is monitoring the file.
The file may still contain uncommitted changes.
Mistake 3
Confusing Modified and Staged.
Modified:
The file has changed.
Staged:
The changed file has been selected for the next commit.
Mistake 4
Making one large commit containing unrelated work.
Instead, create smaller commits with a single purpose.
This keeps project history clean and understandable.
Best Practices
Understand file states before learning advanced Git commands.
Stage only related changes together.
Commit frequently with meaningful messages.
Review your changes before committing.
Keep commits focused on one logical task.
Summary
Git manages every file by assigning it a specific state. New files begin as Untracked, become Tracked once Git starts monitoring them, change to Modified when edited, move to Staged when prepared for a commit, and finally become part of the repository once Committed.
Understanding these file states is essential because almost every Git command changes a file's state. Once you understand these transitions, Git becomes much easier to use and troubleshoot.
Comments
Post a Comment