We also migrated from TFVC to git. When you are in TFVC, it is harder to have merge conflicts, because specific files are checked out, and everybody can see who has what checked out in their own solution. So basically you can work out conflicts ahead of time person-to-person. "Hey are you done with that file yet? I need to check it out." Therefore we never had merge conflicts. At least from what I remember.
Git's model is different, and merge conflicts are a natural consequence, not necessarily an indication that you are using it incorrectly. When two people separately change the same file, the possibility of a merge conflict increases. If they both change the same line, a conflict is almost guaranteed. Maybe the file needs to be split or maybe only one dev needs to work on that subsystem. Probably the pain of a merge conflict will lead you in those directions anyway.
Branching is quite useful (also available in TFVC), but will not directly prevent merge conflicts. I create a branch for every user story / backlog item / whatever-you-call-it. My co-worker generally creates a personal branch and does his work there. Either way, when work is complete (workflows may include pull request / code review, etc as definitions of "complete"), we both merge our branches (or accept the PR) back into "master". Sometimes we have to resolve merge conflicts which might or might not require coordinating with each other. After a merge, I delete my feature branch since all the commits are now in master. When we deploy to production, we merge master into a 'release' branch and tag the latest commit with a release version. That way if we discover a bug affecting production, we can immediately switch to the currently-in-production code, test and fix, redeploy, tag and merge the fix back into master. We can also roll back to previous released versions by tag.
Not sure if that helped your problem.
Note: we are not advanced git users... we use it as lightly as we can get away with for our processes. But we use more features than we used in TFVC.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We also migrated from TFVC to git. When you are in TFVC, it is harder to have merge conflicts, because specific files are checked out, and everybody can see who has what checked out in their own solution. So basically you can work out conflicts ahead of time person-to-person. "Hey are you done with that file yet? I need to check it out." Therefore we never had merge conflicts. At least from what I remember.
Git's model is different, and merge conflicts are a natural consequence, not necessarily an indication that you are using it incorrectly. When two people separately change the same file, the possibility of a merge conflict increases. If they both change the same line, a conflict is almost guaranteed. Maybe the file needs to be split or maybe only one dev needs to work on that subsystem. Probably the pain of a merge conflict will lead you in those directions anyway.
Branching is quite useful (also available in TFVC), but will not directly prevent merge conflicts. I create a branch for every user story / backlog item / whatever-you-call-it. My co-worker generally creates a personal branch and does his work there. Either way, when work is complete (workflows may include pull request / code review, etc as definitions of "complete"), we both merge our branches (or accept the PR) back into "master". Sometimes we have to resolve merge conflicts which might or might not require coordinating with each other. After a merge, I delete my feature branch since all the commits are now in master. When we deploy to production, we merge master into a 'release' branch and tag the latest commit with a release version. That way if we discover a bug affecting production, we can immediately switch to the currently-in-production code, test and fix, redeploy, tag and merge the fix back into master. We can also roll back to previous released versions by tag.
Not sure if that helped your problem.
Note: we are not advanced git users... we use it as lightly as we can get away with for our processes. But we use more features than we used in TFVC.