The Trunk and
The Branches, every developer with Subversion experience knows what it mean. For those who are not familiar with it, each Subversion repositories should contains four (4) directories. Each directories have their own purpose and they need to be use wisely.
The trunk contains the most current code. It is basically the code that is running in production. There's only one trunk in your repository, take care of it.
Unfortunately, people use this to fix bugs or create new features. They checkout, update the code and push to production. This practice should be banned since that can generate more issues than you can imagine. The trunk is only used to create branches, tags and releases.
Branches are a copy of the trunk. These branches are created independently and can be used to add, modify or delete features to the current code and to fix bugs. With that said, there is two (2) types of branches you need to consider:
Feature branch is mainly use to add, modify or delete feature to your current code. Naming your branch is a very important step. If you have a ticketing system that is use to create request to developers, I recommend to use the ticket id.
For example: A business analyst request a new feature and the ticket number of this ticket is 102, then the branch name will be:
This will simply your life when it's time to go back to the original request to make sure you didn't forget anything.
If you don't have such a system, you will have to generate a good name so it is easy for everybody to remember.
For example: John Doe, (a business analyst) request a new feature, he sends is request by email to the project manager and the project manager sends an email to you. In this case, you can name the branch using the initial of the business analyst with the date/time when the email was sent to the project manager:
The "Bug Fix" branch is mainly to fix bugs found by QA or you in the current code (trunk). These kind of branches are created for this purpose.
The naming convention for these branches should follow the same logic as the "Feature Branches". The only exception is the
fix- added as prefix. This way, it is easy to find and track back what was fix and for which purpose.
Tags are like branches that are not used for development. In other words, they are "snapshot" with a name of a specific revision of the trunk, or of a branch.
The naming convention for these tags should follow the same logic as the branches.
Releases are combined branches ready to be tested and pushed to production. Pushing one branch at a time can be painful to test, push and merge. If you have 4 branches that needs to be tested and pushed, this is what you need to create. Because it combined multiple branches, you don't need to repeat the same process over and over.
The naming convention for these releases should follow a date/time standard. For example, a release that was create on Monday, Sept 19th 2011 11:00:00 should have the name:
20110919-110000. This way, it is easy to go back and know at what day this release was pushed to production.
When committing releases, the name of all branches should be included.