Originally Posted by Nesh108
I rarely use the merge tool when I work with source control software. Rather I tend to use diff tools more often to identify the location of problems, then I go and manually fix each one. It's time consuming, but this is the best way to ensure the correct changes get made to the source code.
I'm not too familiar with git in particular, but I know other repo software allows you to checkout/lock files. While locked, only the user who has the file checked out has checkin/commit abilities for that file. This is particularly useful for binary files (good luck using a diff tool on these
). However, I have seen quite a few times where developers forget to check-in/unlock a file preventing auto-build scripts and other developers from accessing the file leading to a whole new collection of problems.
I would personally not recommend going this route as it's really avoiding the bigger issue which is the format of the code base and work division.
My suggestion? Divide work to minimize file version conflicts as little as possible and commit/update often (use descriptive comments! It makes debugging much easier). The best way to deal with version conflicts is to avoid them. Get the developers together and hatch out what everyone is responsible for before coding even begins (some teams like weekly meetings, others meet for a few minutes each morning). This is probably the best way avoid conflicts. Coding shouldn't be the time a developer is working out the structure of a program.