Concept of git tracking and git staging

Question

When you modify a file in your working directory, git tells you to use "git add" to stage.

When you add a new file to your working directory, git tells you to use "git add" to start tracking.

I am a bit confused about these 2 concepts because i assumed tracking a file for changes is different from staging it for commit

Scag

Answer 1

Git has a concept known as 'the index'. To create a new commit, you fill the index with the contents you'd like to have in the next commit. That means that you have to explicitly tell Git which changes you want to appear in the next commit by using git add. (git add -p to add only single hunks)

It doesn't make a difference to Git whether you only update a file (»stage changes«) or if you add the full content of a new file (»start tracking a file«) – both times, all that Git's index sees is the addition of new changes

Allochthonous

Answer 2

Git essentially has 4 main statuses for the files in your local repo:

• untracked: The file is new, Git knows nothing about it. If you git add <file>, it becomes:
• staged: Now Git knows the file (tracked), but also made it part of the next commit batch (called the index). If you git commit, it becomes:
• unchanged: The file has not changed since its last commit. If you modify it, it becomes:
• unstaged: Modified but not part of the next commit yet. You can stage it again with git add

As you can see, a git add will track untracked files, and stage any file.

Also: You can untrack an uncommited file with git rm --cached filename and unstage a staged file with git reset HEAD <file>

Tigre

So I take that a tracked file can either be staged, unstaged, changed, unchanged? What's the use of tracking a file without staging it? – Fley

Answer 3

When you add a file to start tracking, it also stages its contents.

If you want to add a file for tracking without staging it, you can use

git add -N

Emergent

what's the use of tracking a file without staging it? – Fley

Answer 4

Both of the git add steps you identify do essentially the same thing, they simply have different explanations because of their arrival route.

The git add simply tells git that the file provided is a file that you desire to have, in its exact current form (its content), within its source control repository. At that point git will take a snapshot of the file (and it keeps a note in its index) so that it is ready for when you have all your changes to your files ready and added (i.e marshalled together in the staging area), for your git commit (with appropriate message ;-).

Once git has been told about that file (e.g. @avh's -N option) it will notice (track) changes to the file under the guise of various commands (such as git status). Thus, later, you have to explicitly tell git when you no longer want a file to be tracked (git rm <file>), and you can continue editing a file (locally) after you have added the version that will be in the commit. Almost obviously (or perhaps not), you can git add a file many times before you commit the final version.

Blumenthal

Careful, git rm will delete the file from the working directory. It won't just untrack it. – Summitry

Answer 5

Let me explain Git's Three Tree Architecture, which includes a working directory, a staging index, and a repository:

When we move a file from the working directory to the staging index, git begins tracking the changes, indicating that the file is staged (in the staging index), and because it is also tracking the changes, we can say that the file is tracked.

There is a distinction between the file tracked in the staging index and the file tracked in the repository. When changes are committed to the repository, they become part of the repository history, whereas changes in the staging index have no effect on the git history.

Feigin