Working in a team is actually not that straightforward. Normally (actually there should be!!), there is a version control system (CVS, SVN, TFS) in place which allows more people to work together on a project. But that's not enough. People need to be aware that they're not working alone on the project and have therefore to use the version control system appropriately. "Of course" you would think, but it sometimes doesn't seem that clear to people.
The number 1 rule: NEVER EVER upload a broken build to the common repository!!
Why that?? Well, because the next time your team members are fetching the latest versions, they'll have a broken build on their local development environment, which will not allow them to continue to work on the code.
Don't get me wrong, it's not that it never happened to me that I accidentally uploaded some broken build. Anyway, I started to think about some guidelines for working with version control systems, lets call them best practices:
- ONLY check-in working code
Checking-in or committing only working code is essential. If you don't do so, you'll break the build.
- Check-in often
Don't check out in the morning and check-in in the evening!!
Checking-in in short time frames has several advantages. For the first you have always only checked out the code you're currently working on, which helps you keeping the overview and secondly checking-in is somehow a backup of your work. Lets assume the case that you've implemented something wrong or you made a mistake which broke your whole build. If you checked-in constantly, you can just revert to a previous version.
So the advice is: implement a use-case (if it isn't to large) and after successful implementation commit it to the repository.
- Fetch the latest versions regularly
It doesn't cost you anything! Retrieve the latest source code versions regularly to stay up-to-date. Assume you're working on a piece of code which makes use of functionalities provided by other source-code modules which you're not currently working on. Those functionalities may change while you're working on your code. Method signatures may change which may break your running-code. By fetching the latest version you can immediately react to those changes.
- Write comments on the files you check-in to the repository
Sometimes this may be annoying, but it may help you, especially when there comes the situation when you have to revert to a previous version. Then comments may help you find the right one.
- Open your programming environment and fetch the latest versions from the repository
- Compile and build the system to see whether there are no problems.
- Check out the files where you have to work on and implement your use-case.
- Once finished, make sure that everything compiles without errors.
- Again, retrieve the latest versions from the repository.
- Run a project build to see whether still everything compiles and works fine.
- If it does so, check-in your changes and add a comment to what you've done.
- (Continue with step 3)
So happy coding ;)