Rules to Better Version Control (aka Source Control)

Source control is the backup of your code, as well as your tool for tracking changes over time.

With source control, we can share project code and collaborate with other team members. Using it allows us to track changes, compare code, and even roll-back if required. Moreover, it keeps our code safe and that is the most important part.

When checking code into TFS, a build should be triggered as per the rule Do you know the minimum builds to create on any branch?

You should not just trigger a build and walk away however – make sure that build succeeded!

Gated Checkins are great for verifying your project builds successfully before a checkin occurs, but the workflow and dialog messages can be difficult to follow. Sometimes it’s not clear what you need to do next as a developer.

Check-in policies are a great way to enforce code quality before it hits your source control repository. SSW recommends that the following check-in policies be enabled by default on your project:

1. Changeset Comments Policy - To enforce that all check-in contain comments
2. SSW Code Auditor - To enforce coding standards and best practices before check-in
3. Work Items – To ensure check-ins are linked to a Work Item in TFS

Too many people treat Source Control as a networked drive. Don't just check-in when the clock ticks past 5 or 6 o'clock. If code doesn't pass its unit tests or won't even compile put your code in a shelveset.

Never allow a situation where a developer can check outcode and the code does not compile – or the unit tests are not all green. This is called “breaking the build” and the punishment in our office is 20 push-ups and fixing broken links for an hour!

Note: If you did not finish working:

• TFS put changes into shelveset
• SVN put changes into sandbox / branches

New, Bug or Refactor should be the prefix.

Here are some examples:* New P112: Added a new control for DateOfBirth

• Bug P113: Fixed validation to now allow US dates
• Refactor: Moved the email regex from inline to a resource file

Team Foundation Server is great, and one of its neat features is enforcing comments when checking in code. Without comments, some of the other built in features like History become redundant without comments.

You can spend valuable developer time on every part of a project. The bulk of time is normally spent on coding up .cs, .vb, .resx and .aspx files. However, you could potentially have the following happen if you do not include other files in source control:* lose work

• lose old versions of work
• have work overwritten