What are the differences between git file states (untracked, unmodified, modified, staged)?

15

I would like to know what characteristics and differences between the states of the files during their life cycle in git .

States :

  • untracked
  • unmodified
  • modified
  • staged

    
asked by anonymous 30.08.2018 / 12:17

2 answers

14

I think we can better understand these states by creating a project from scratch. First I will create a folder called "project" and enter it:

$ mkdir projeto
$ cd projeto/

For now it is empty. I'll use git init to initialize it as a git repository:

$ git init
Initialized empty Git repository in C:/Users/usuario/projeto/.git/

Now I'm going to start my project by adding a file (with the "hello world" content inside it), and then check the status of this file with git status :

$ echo "hello world" > hello.txt

$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        hello.txt

nothing added to commit but untracked files present (use "git add" to track)

Notice that the hello.txt file is listed as " Untracked files". That is, git is not " tracking " this file. We can say that git is not controlling the life cycle of this file (and I confess I do not know if "life cycle" is the technically correct term).

It's like git says: "I saw that there is a file here, but I'm not responsible for it."

In order for git to be responsible for this, use add :

$ git add hello.txt

$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   hello.txt

Now the file is listed as " Changes to be commited" , that is, it will be part of the next commit. The file is then said to be " staged " (or is in the stage area , or index / em>, I do not know why so many names for the same thing ).

In any case, note that there is even an instruction to remove the file from the staging area ( use "git rm --cached ..." to unstage > ).

Instead of unstage the file, let's commit it (I love these foreigners ...) / sub>

$ git commit -m"Primeiro commit"
[master (root-commit) ccc2a05] Primeiro commit
 1 file changed, 1 insertion(+)
 create mode 100644 hello.txt

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

After the commit, git status says that there is nothing to show (nothing to commit, working tree clean ), meaning all files are up to date: content hits with the last commit, there was no change). It can be said then that the hello.txt file is unmodified (no changes compared to the last commit).

So let's change the file by adding some text to its end:

$ echo "Novo texto" >> hello.txt

$ cat hello.txt
hello world
Novo texto

Now the file has 2 lines, let's see what git status shows:

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   hello.txt

no changes added to commit (use "git add" and/or "git commit -a")

It shows that the file is modified , that is, it has been modified compared to the last commit. But note that this modification will not be in the next commit, because the file is listed as "Changes not committed for commit" and at the end the message "no changes added to commit" in>.

I can see the modifications using git diff :

$ git diff
diff --git a/hello.txt b/hello.txt
index 3b18e51..7d34649 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1 +1,2 @@
 hello world
+Novo texto

The +Novo texto excerpt indicates that this line has been added ( + ). To make the change available at the next commit, just use add :

$ git add hello.txt

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   hello.txt

Notice that the file continues to have a status of "modified" (after all, it is different from the last commit), but will now be in the next commit.

That is, it is both modified (different from the last commit) and staged (because it is in staging area ) .

Being in the staging area causes diff to no longer show the differences:

$ git diff
(não mostra nada)

To know what has changed, you should use the --cached option, which compares the staging area (also called cache ) with the last commit: / p>

$ git diff --cached
diff --git a/hello.txt b/hello.txt
index 3b18e51..7d34649 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1 +1,2 @@
 hello world
+Novo texto

By the way, --cached is equivalent to --staged - that is, compares the files that are staged with the last commit.

In short:

  • untracked: git knows nothing about the file. I mean, you even know it exists, but it will not control your life cycle.
  • staged: those in the staging area / index / cache . These are the ones that will be in the next commit
  • modified: those that have been changed compared to the last commit
  • unmodified: unchanged
31.08.2018 / 15:34
9
Untracked is the state where the file has not yet been 'crawled'.

  • Unmodified is the state where the file has not changed in relation to your reference.

  • Modified is the state where the file has changed relative to your reference.

  • Staged is the state where the file has already been addressed and is waiting to be transferred to the repository.

    Notice in this link which commands are used in each step of the process until the file is added to the repository. I believe it will help in understanding.

    In addition, follow good references links: Git - Book | Git - Practical Guide

        
  • 30.08.2018 / 15:53