As Jeff Atwood says not all universities seem to teach very much about source control and deployment. I know of at least one that provides source control for a group project but doesn’t provide any guidance for example.
Here’s what I’d like all students to be taught when they do their first group project and are given access to a source control repository.
Learn what not to check in.
Don’t check in derivatives. The object files and binaries produced as a result or by product of the build process shouldn’t be put under source control.
As a general rule of thumb don’t check in binary files. The key exception to that are the binary resources like images and icons you need to build your program.
Generally don’t check in files that are built as part of the build process. Don’t check in user settings files that differ on every PC.
The key reason to not check these in is that they will cause conflicts preventing you from checking in the code.
Lets take as an example the executable that your source code is built into. You check that in and developer 2 checks it out. They modify the source code and rebuild. They then check in their changes and the new executable. You meantime continue development too. You have rebuilt the exe and tested it and come to check in. You have to do an update first because of developer 2’s changes. Unfortunately the source control system cannot resolve the differences between their new executable and your new one because it’s a binaray file so it marks it as a conflict. You then have to resolve that in some way before you can check your code in. If the exe wasn’t in there you would have just needed to do an update and commit. Instead you have to go through an annoying conflict resolution process that isn’t really necessary.
The binary rule generally works because developers of developer tools realise that everything that should be versionable needs to be in text. Non essential resources like intermediate build files and what positions the text windows were in in the IDE are stored in binary for speed. Take my Visual Studio 2005 project as an example. I have a .sln file, a .suo file, a .csproj, and a .csproj.user. The .sln and .prj files are the critical solution and project files that need to be checked in. They are both in text so that they can sensibly exist in source control and be merged. The .suo file isn’t. It’s not necessary to be checked in and if a user doesn’t have it when the solution is loaded Visual Studio will create a new one. The .csproj.user file is in text but I don’t think it’s necessary. Use your brain when checking things in, if you’re not sure you can always check it in and then delete it if you realise it’s not really necessary.
Keep everything relative
Hard coded paths are the bane of source code control. You could enforce that everyone checks out to the same path but that negates all the benefits of being able to use multiple workspaces.
Play with branches on code that doesn’t matter.
Each source code control system has different ways of doing branching, tagging and lots of wonderfully complex features. Goof around with the source control system to figure out how to use it before you need to do it in anger. If you don’t you’ll be too scared to use those really useful but tricky features when you are in a bind and don’t want to damage your precious source code.
Keep everything possible under source control
This is the obvious one, just don’t forget my first point that there are things you shouldn’t check in. Some things are border line and you’ll just have to figure them out yourself.
Think of documentation and sql schema’s to put alongside the code. It ideally all wants to be in text format otherwise you won’t see a lot of the benefits of the versioning system. Ultimately the important thing is that you should be able to go back to a version and be sure what went with it. What structure the database needed to be in and what the documentation said to do.