There are some important things to remember which can serve to make addition of developers to the team simple and make it easy for merging and tracking development streams. The flipside of this is that not following these simple rules can muddy up source control and turn something simple in to something complicated. Here’s some golden rules.
If it is an automated output – it should not be there
IDE’s and build scripts can often generate intermediate or temporary files. You as a developer should know the difference between throwaway files like the ‘.user’ files which Visual Studio creates and the project files which are essential. Face it, there will always be a merge problem between developers when it comes to project files, why make it worse?
If it is copied from somewhere – keep it in one place at the source
There should only ever be one copy of a file. Multiple versions is a big NO NO! If, for example, you have references to a set of DLL files for a few projects in their BIN folders, create a DLL folder up at the solution level and make each project refer to that folder as the source for the ‘hintpath’. By just having copies of DLLs in every bin folder of a solution, you create DLL HELL as versions of libraries change and each developer in the team is at a different stage of development.
If it is crap – flush it, If you see it should not be there – remove it
Make a point of never committing a ‘.bak’ file or any other crazy file which really should not be there, as a developer your job is to introduce order, not chaos. Spend an extra 10 seconds when you are committing to make sure junk is not there. If you are working on a merge or some other task and you notice something should not be there, it is your duty as a citizen of the project environment to clean it up.
Personal configuration does not belong in a repository
Configuration files will always be a point of conflict as they need to be stored for posterity, but not much more. Make a point of only ever committing a ‘golden’ config which acts like a dictionary of ‘config keys’ with example values. The real thing should not be in source control unless you are keeping it as a backup for a server – in which case it belongs OUT of a solution and in a seperate place specifically for that purpose.
