Hey guys,
We've recently migrated from TFVC to Git. We've got 4 teams who are at the end of their first sprint and they're having issues with merges of their branches, clashing with one another, and getting conflicts.
I'm looking for someone who's taken a similar route who can give a bit of guidance, or, alternatively, someone who just knows Git better than we do to give me a bit of an overview of branching and merging best practices. I think we're probably forcing too much TFVC terminology and process onto ourselves and not adopting Git properly, but none of us know Git enough to know where we're going wrong
Cheers!
Greg
Top comments (2)
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.
Hey! I've noticed that in this post you use "guys" as a reference to the entire community, which is not made up of only guys but a variety of community members.
I'm running an experiment and hope you'll participate. Would you consider changing "guys" to a more inclusive term? If you're open to that, please let me know when you've changed it and I'll delete this comment.
For more information and some alternate suggestions, see dev.to/seankilleen/a-quick-experim....
Thanks for considering!