Git tracks content rather than files
Branches are lightweight and merging is easy, and I mean really easy.
It's distributed, basically, every repository is a branch. It's much easier to develop concurrently and collaboratively than with Subversion, in my opinion. It also makes offline development possible.
It doesn't impose any workflow, as seen on the above-linked website, there are many workflows possible with Git. A Subversion-style workflow is easily mimicked.
Git repositories are much smaller in size of the files than Subversion repositories since there's only one ".git" directory, as contrast to dozens of ".svn" repositories (note Subversion 1.7 and higher now uses a single directory like Git.
The staging area is great as you will be able to see the changes you will commit, commit partial changes and do various other stuff.
Stashing is invaluable when you do "chaotic" development, or simply want to fix a bug while you're still working on something else (on a different branch).
You can rewrite history, which is great for preparing patch sets and making edits (before you publish the commits)
Disadvantage is that Git is not great for big binary blobs
Say you have a complex 3D model for the exciting new first-person puzzle game you're making, and you save it in a binary format, resulting in a 1-gigabyte file. You git commit it once, adding one GB to your repository's history. Later, you give the model a different hairstyle and commit your update; Git can't tell the hair apart from the head or the rest of the model, so you've just committed another gigabyte. Then you change the model's eye colour and commit that small change: another gigabyte. That is three gigabytes for one model with a few minor changes made on a whim. Scale across all the assets in a game, and you have a serious problem.
Contrast that to a text file like the .obj format. One commit stores everything, just as with the other models, but a .obj file is a series of lines of plain text describing the vertices of a model. If you revise the model and save it back out to .obj, Git can read the two files line by line, create a diff of the changes, and process a fairly small commit. The more refined the model becomes, the smaller the commits get, and it's a standard Git use case. It is a big file, but it uses a kind of overlay or sparse storage method to build a complete picture of the current state of your data
Back