LuisLlamas Logo
git-ciclo-vida-archivos

The File Lifecycle in Git

  • 6 min
  • Beginner

In the previous article, we initialized our repository. Now we have a folder monitored by Git. But we already said that Git does not start saving things automatically.

To understand how to use Git, we first need to understand some core concepts of how it works internally, which can be quite confusing at first:

  1. The 3 Areas: The physical places your code travels through before being saved.
  2. The 4 States: The labels Git gives to your files based on what you have modified.

Take heart, if you understand this, you have 50% of Git understood. Let’s get into it 👇.

The Three Playing Fields

Imagine your project is divided into three main areas:

  • Working Directory: This is your real folder on the hard drive. This is where you create, edit, and delete your files while working normally.
  • Staging Area: This is an intermediate zone. Here you place files that are ready to be saved in Git.
  • Repository: This is Git’s database (the hidden .git folder). Once files arrive here, they are saved as a permanent “snapshot” in your project’s history.

Files pass through these three areas until they reach the safety of the Repository, where they are saved and protected 🔒.

The one that’s usually hard to understand is the Staging Area. Think of it as a temporary zone where you “prepare your things” before actually saving them.

Git States

As your files travel through these three areas, Git attaches different labels to them to know what situation they are in.

These labels are the 4 states a file can be in, from Git’s perspective:

Untracked: These are files that exist on your hard drive but Git knows nothing about them. If they are modified or deleted on the disk, Git will not be able to recover them.

Unmodified: The file is tracked by Git and is identical to the version saved in the database. There are no pending changes.

Modified: The file is tracked, but you have changed something since the last time you saved. However, you haven’t yet said you want to include that change in the next snapshot.

Staged: You have modified a file and marked it to be included in the next commit. It’s in the “loading area”.

Lifecycle Simulator

Let’s stop imagining and see it. Here we have a simulator that graphically represents what happens in Git’s “guts” when you move files.

Before continuing in the course to see Git commands, let’s play a bit to understand the concepts well and what happens at each step.

Untracked

You will see two files in your Working Directory with a green U label.

This simulates Untracked files on your computer. Git detects them, but understands they are not its business.

Move to Staged

Now press the + button on one of the files. The file is “copied” to the central column Staged Changes. You have executed a git add.

Now the file is Staged. Git has taken a provisional snapshot and left it in the preparation area, ready to be saved.

The Commit

Type a message in the center text box (e.g., “My first file”) and press Commit. The file disappears from the center and is recorded in the right column Repository and below in the history.

Now the file is Unmodified. It means the version you have in your working folder is identical to the one saved in the database.

The Modified State

Here comes the interesting part. Go to the simulator and find the file in the left column Working Directory. Press the ✏️ (Edit) button.

The version changes (from v1 to v2) simulating a change. The label becomes Modified. Git has detected that the version it has does not match the one you have.

To save this change, you would have to repeat the cycle:

  • Press + to upload the v2 to the Stage
  • Do Commit to save it in the Repo

File in Two States at Once

It may seem curious, but it is possible to have a file in two different states. For example, if you modify a file, add it to the Stage, and modify it again before committing.

Try it in the simulator:

Press + (the v1 moves to the center).

Press ✏️ again on the left (it changes to v2).

Now you have the same file in two places:

  • In Staging you have the v1 ready to be saved.
  • In Working you have the v2 waiting.

If you commit now, the v1 will be saved. The v2 will remain on your hard drive waiting for the next cycle.

Repository Status with git status

The git status command is used to know the exact state of your project.

Whenever you don’t know what you’ve touched, what you have left to upload, or what state your project is in, you run git status.

git status
Copied!

Git will return a report dividing your files into logical groups according to the three areas we already know:

  1. Changes to be committed: Files that are in the Staging Area, ready for commit.
  2. Changes not staged for commit: Files that are Modified, but still in your Working Directory.
  3. Untracked files: New files that Git is ignoring.

Furthermore, Git always gives you hints. It tells you exactly which commands you can use next to move files from one state to another (like git add or git restore).

git status -s: The Short Version

When you’ve been using Git for a while, the default output of git status will seem very verbose. It takes up a lot of screen space. You can use the “short” option:

git status -s
Copied!

It will return something like this:

M leeme.txt
?? nuevo_archivo.js
A  otro.css
Copied!
  • ??: Untracked.
  • A: Added (New file added to the Stage).
  • M: Modified.

M has two columns:

  • M red (right): Modified but not staged.
  • M green (left): Modified and staged.
  • MM: Modified in the stage and modified again (the double state case).

On this page