You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The staging area (aka index) is a container where git collects all changes which will be part of the next commit.
If you are editing a versioned file on your local machine, git recognizes that your file is modified - but it will not be automatically part of your next commit and is therfore unstaged. Staging the file will put the file into the staging area (index). The next git commit will transfer all items from staging area into your repository.
What is this good for? Imagine you are in hectic and you have to fix a few bugs in your software. Usually you edit your files and fix simultaneously several bugs. After this you have a lot of unstaged but modified files. On the other hand you want to have "clean" commits: each commit should be definitively related to a single bug only. Using the staging area you could collect all changes referring to a single bug and make a clean commit - in your next step you stage all changes for the next bug and make the next clean commit ...
You could not only stage complete files - but also "hunks" (parts of a file) and even single lines from a modified file (sourcetree is a great tool for preparing the staging area with great facilities for staging files, hunks or lines).
Resumee: Editing a versioned file makes the file modified, but unstaged. Staging the file/hunk/line adds the change to the staging area. The changes within the staging area are part of the next commit. The commit transfers all changes from staging area into your repository. The staging area allows you to collect all changes to get a "clean" commit.
Hope this was clear