The “file locking” system you’re describing was a system implemented in older version control systems that didn’t support three-way merges. Forcing a developer to “check out” a file, thereby preventing anyone else on the team from doing the same, was a method of preventing two developers from changing the same file at the same time, creating a merge conflict … at least on those older version control systems. There were a lot of related problems with these systems, like your team’s development speed getting slower the larger the team or more complex the project in some cases, people circumventing the lock system, people forgetting to check a file in then going on vacation, and etc.
Modern source control systems, like Git, use three-way merges, when necessary, to resolve merge conflicts automatically in the majority of cases. This allows everyone to work on what they need to, when they need to, without fear of most merge conflicts. This results in faster teams and fewer frustrations all around.
The only case where Git supports file locking is in the case of using Git LFS (Large File Storage). Git LFS is designed to deal with large binary files and binary files can’t be diff’ed and merged, so the old-fashioned file locking has to be used in that case.
I suspect that if the Visual Studio plugin supports file locking, it is only in the context of Git LFS. I’ll check with the team to confirm. But in the meantime, I suggest looking at some standard Git workflows and seeing if they’ll work for you.
Let us know if you have any more questions!