TFS uses MD5 for its checksum. When you upload a file as part of a changeset or shelveset, you also send the MD5 that you calculated. The server will also calculate the MD5 of your upload contents to validate that there was no corruption on the wire. Similarly, when you perform a Get from the server, it will deliver the MD5 of the content and clients will validate that the checksum matches.
As to your question about corruption, I can only speak hypothetically and only from having worked on TFS. Obviously if your database is corrupt, all bets are off and we make no guarantees as to anything.
When you say "a TFS checkout" (after having discussed "a git checkout" above it), I assume you mean "a TFS working folder mapping". The only problem should be when you try to do a get of the corrupted file. For example, if you had a corrupt $/Foo.cs at changeset 42 and you did a get of changeset 42, then it would fail. Your local version would not be updated on-disk or on the server and you would not be at version 42 locally.
If, however, there existed a $/Foo.cs at version 43 and it was not corrupt, then you should be able to get changeset 43 without problems. The server would not examine that previous version.
If you had gotten $/Foo.cs at changeset 42 before the database became corrupt, you should be able to check the file out (in the TFS terminology of "checkout", meaning to pend an edit), make changes, then check the file in, but there's certainly no guarantee of this. You would need to make changes, since if a client tries to produce a changeset or shelveset that includes a file with the MD5 of the current shelveset, the server will instruct the client not to bother sending the changes.
Again, this is all fairly hypothetical. We didn't exhaustively test data corruption scenarios. Realistically, if your database is corrupt, all bets are off and you should restore from a backup.
