The book Pro Git says that the staging area is just a list, or index, that says which files will be committed when a git commit
is done, and now the name index
is more commonly known as the "staging area".
But if we modify the file foo.txt
that is already part of the repo, and use git add foo.txt
to stage it, and modify the file again, now the file is both "staged" and "modified" (as seen in git status
), and if we commit, the "staged" version will go into the commit. The second edit won't go in.
So how can the "staging area" keep track of what the first edit was if it is just an index -- a list of files?
The staging area can be described as a preview of your next commit. When you create a git commit, Git takes changes that are in the staging area and make them as a new commit. You are allowed to add and remove changes from the staging area. The staging area can be considered as a real area where git stores the changes.
A staging step in git allows you to continue making changes to the working directory, and when you decide you wanna interact with version control, it allows you to record changes in small commits.
The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git parlance is the “index”, but the phrase “staging area” works just as well.
The Git index is a critical data structure in Git. It serves as the “staging area” between the files you have on your filesystem and your commit history. When you run git add , the files from your working directory are hashed and stored as objects in the index, leading them to be “staged changes”.
Index is a view of your working directory that is ready for commit. It can be seen as a pre-commit state and is not as simple as a "list of files". When you do git add
, the file (with the change) is added to the index and the newer changes will not be see until you add them too.
The index
is like an out basket of completed work. At any point you can add
a (part) completed file to that out basket and it will replace the previous copy with your current copy, so that when you finally decide to commit
it will use the contents of that out basket (the current index
) to create the commit.
In addition your earlier add
will have create a blob object within the repo that can be found if required via the various logs. After a while (30 days+) it will disappear with gc
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With