Does Visual Studio allow a user to choose to commit all their changes, ignoring what's in the remote?

Question

Where I work, we are still using TFS, with TFVC. I'm hoping to get my colleagues to adopt Git, but that's a slow process.

One really bad habit of my some of my colleagues, when checking in code changes, is to check in all their changes, ignoring what's already in TFS. This is a function of Visual Studio. When performing a check-in, if Visual Studio detects a conflict, and if the developer chooses to review the conflicts, there is a button in Visual Studio to accept all the user's changes and ignore the changes in TFS. They always choose that option, blowing away other people's work. I've tried to change that behavior the last 5 years. I now realize they're just going to do it that way. Honestly, they'd be better off working alone, because of this behavior of removing other developer's changes.

I'm wondering, when Visual Studio works with a Git repo at a remote, like Azure DevOps Services or GitHub, does Visual Studio give the developer a choice, when resolving conflicts, to just shove all their changes in the push, or does Visual Studio insist upon the user performing a pull, before it allows them to push changes to the remote?

Answer 1

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).