Using a source control is a must especially when working in a team. This post will describe some general guidelines that can help maximize its usefulness and efficiency.
Branching strategy
When starting a new project the first thing that needs to be decided is a branching strategy. Branching strategy will dictate what branches you will have and to which branch will you commit certain changes. The approach that I have found most useful is to have 3 branches:
- Main - this branch holds the latest stable version of the code.
- Release (multiple branches) - each release branch holds a production-ready code for a certain version of the project. There can be many release branches.
- Development (multiple branches) - each development branch corresponds to a certain work unit (e.g. - sprint, functionality, module, etc). Development branch is where all the work happens. A new development branch is created for each new work unit.
The advantages of this setup are
- Ability to deploy to production at any time.
- Multiple teams can work on separate pieces of functionality simultaneously.
- Hotfixes are made possible (by applying changes to one of the release branches).
- There is always access to the latest stable version of the code (main branch).
This branching strategy is actually very popular and is described in more detail in here.
Guidelines for committing changes
Once the project is underway and people start committing code, I found that it helps to follow these general guidelines:
- Always leave a comment describing what has been done. This comment should be short but precise.
- Do not check-in unrelated work under one changeset.
- Minimize the size of the changeset by grouping work into smaller logically related pieces of functionality and checking in each logical unit separately. For example if you are working on a story “implement login functionality”, you might want to split the story into 3 logical pieces (with each checked-in separately):
- implement login functionality up to the business layer.
- implement web page for login.
- implement logic checks on all pages and if user is not logged in, redirect to login page.
- If the story you are working on requires some general functionality that isn’t directly related to the business requirements (e.g. - xml manipulation), then you should implement and check-in that general functionality separately.
This is all for now, but I will update this post as I get more ideas.