RodAtWork avatar image
0 Votes"
RodAtWork asked cooldadtx commented

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

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?

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

cooldadtx avatar image
1 Vote"
cooldadtx answered cooldadtx commented

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

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thank you, @cooldadtx. This is one of the many reasons why I love Git over TFVC. I know, from experience, that when I tried to push changes to the remote from my laptop, if I had previously added changes from my desktop, that Git would stop me from doing so, then require me to resolve the merge conflicts. I've always considered this to be better than what I've seen with TFVC.

However, where I work there's a significant number of fellow developers who often check-in code, wiping out other people's work. I had this happen to me on Monday. We have an app that wasn't installing correctly for users. Last Friday I was asked to work on it, because one of my colleagues who'd been working on that project wasn't in. I discovered that he had spent a lot of time adding in lots of NuGet packages which were all intended to be used to write Visual Studio extensions - certainly nothing a line of business app needed. I spent all of last Friday removing them.

1 Vote 1 ·

(Cont.) On Monday, my colleague returned, added some new class, then checked it all in. I'm sure he received a message from VS telling him there was a conflict. His habit is to choose the button accept all local changes, thus wiping out everything I'd done. He's done this to me before. I know of other developers who do the same thing in projects they work on. I used to think they were being belligerent, but now I think they just don't know any better. And although I've told him multiple times over the years to do a get latest on the solution, he often just shoves his code in, blowing away whatever's there.

This behavior is too often done, by more than just this one colleague. No amount of instruction from me has done anything to change that.

I'd like to move us to using Git, over TFVC. I see by your answer that Git will improve things, but it will still be possible, within Visual Studio, to force a push of one's changes into the Git repo. All I can hope is that Git will be more forceful, so that it will give more of my colleagues a pause. Maybe make some of them from ignoring changes entered by others.

0 Votes 0 ·

Git won't allow conflicts so devs will have to explicitly take the local copy over the remote. However Git also has the 'Blame' feature in the UI so you can see who checked in changes and stomped over stuff (or anything for that matter) so it is easier to figure out who did it and why.

Also, I would recommend that you move to a PR-based check in to your master/main branch. This allows you to set up requirements before changes are made to your core branch. In general I recommend that you require a code review from another dev (not the same dev). This helps ensure that somebody doesn't check in "bad" code by having someone else review it. Who reviews it is up to you. On my team we rotate the every sprint. Beyond the standard benefits of peer review this also makes it obvious when someone just stomps over changes. A discussion can then be had about why this is being done.

Another benefit of PRs is that you can also configure your CI build to run. This also helps ensure that no changes are checked in that don't build. But all this can be added piecemeal as your team matures.

2 Votes 2 ·