Git has three main states that your files can reside in.
Working Directory
Staging Area
Local repo (Commited)
Working Directory
Working Directory is a state where you have changed the file but have not committed it to your database yet
This state may contain tracked and untracked files
Untracked files will not be tracked in git unless you commit the file
Staging Area
This state means that you have marked a modified or untracked file in its current version to go into your next commit snapshot
Staging area can contain multiple files
The technical name of this state is “index”, but it’s referred as staging area everywhere
Local repo (Commit)
Commit is a state where your data is safely stored in your local database
Git stores the metadata and object database for your project in this state
When you make a commit, git takes a snapshot of your code into `.git` directory
Basic git workflow
Create or modify a file in your working directory (aka working tree)
Selectively stage just the changes you want to be part of your next commit, which adds only those changes to the staging area
Make a commit (aka checkin), which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory
Basic git workflow
How Git store and retrieves data
Snapshots, Not Differences
The major difference between Git and any other VCS (Subversion, Perforce, Bazaar, etc. ) is the way Git thinks about its data
Most VCS work by delta-based version control (They store as a set of files and the changes made to each file over time)
Git thinks its data as a stream of snapshots (Like a series of snapshots of a miniature filesystem)
Git stores a reference to that snapshot every time you make a commit
This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS
How Other VCS stores file changes?
How Git Stores file changes?
Nearly Every Operation Is Local
Unlike most CVCS systems, most operations in Git need only local files and resources to operate
All operations seem almost instantaneous, as the entire history of the project is right there on your local disk
You can browse the history of the project, play with commits, make a new commit (without network connection) and finally sync your changes when you’re connected back to internet which is not possible with Perforce, Subversion, CVS, etc.
Git has integrity
Everything in Git is check summed before it is stored and is then referred to by that checksum
Git uses SHA-1 hash mechanism which is a 40 character string composed of hexadecimal characters (0–9 and a–f)
A SHA-1 hash example 24b9da6552252987aa493b52f8696cd6d3b00373
Git stores everything in its database by the hash value of its contents
Git only adds data
Most actions in Git result in adding data to the Git database
Once you commit a snapshot into Git, it is very difficult to lose