Not registered yet?
Register now! It is easy and done in 1 minute and gives you access to special discounts and much more!
The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, git add doesn't really affect the repository in any significant way — changes are not actually recorded until you run git commit.
You can use a .gitignore file to remove unwanted files that we can generate or download
Ex: dll, node_modules.
This link shows you how to add a .gitignore file to your repository
git add both marks the file as tracked, and copies it to the staging area. Copying to the staging area before you commit allows one to build up a commit in pieces, particularly useful with git add -p and git add -i.
git add -p
git add -i
You can use git add --intent-to-add to only track the file, but eventually you will need to add and commit it.
git add --intent-to-add
The good news is Git will compress those files, so after committing them and running git gc they should be substantially smaller, assuming they're compressible.
If you commit changes to large files, particularly large binary files, your repository will get very large. Instead use Git Large File Storage to store the history of the large files in the cloud.
.git folder tracks all versions of the tracked files. git add will mark changes (by copying them to a staging area), then git commit will record them in the repository. Yes, it literally stores all the contents of your files; not only that, but all versions of the contents. Otherwise it would not be much of a version tracker - without recording the contents in a separate location, the only way I can think of to go back to an earlier version of a file would be a time-travel machine, and git doesn't implement one yet. :)
That said, git was developed to track source files, and it is very unlikely you have 600MB of source files. You should avoid adding data files, or files that are products of your code or the compilation process (and, for a different reason, any configuration files that can differ per developer). To help with this, one of the first things you should do in a repository is to craft a .gitignore file, and check with git status whether any files you would not want to commit are considered by git.