Yes you can do that but it is generally the wrong approach. Even in TFVC this is a bad pattern to follow. What this tells me is that your devs check out code once and then eventually check everything back in relying on no conflicts. In this case personally I would have configured TFVC to use exclusive check outs which means only 1 dev could check out a file at a time. This eliminates the problem in TFVC but at the cost of slowing everyone down when more than 1 person needs the same file.
In Git you can do the same thing but it is automatic. Git works based upon file diffs. When you pull down changes from Git it compares what you have locally to what is on the server. If there are differences then it'll prompt for you to resolve the conflicts. Normally you'll use the editor to manually select the parts from local/remote that you want to save but there is an option to completely accept the local file (bad) or the remote file (not much better).
The same process happens on a push (which mimics the scenario you're talking about). Git won't let you commit changes that conflict so when your devs push their changes to Git it'll detect that changes are on the server that they don't have. It'll fail the request and, on newer VS updates, give you the option of Pull & Push which will pull down changes locally, attempt to merge the ones it can and force you to fix the others. Then it'll create a new commit locally. After that you will push again and it'll push all the changes merged with what is on the server. Hence you shouldn't lose any changes made by anybody else (unless you accept local file changes which is, again, generally a bad idea).