Source code management and branching strategy
February 13, 2010
A simple but effective source code management and branching strategy for web development projects
Why do you need source control
For any software development team, large or small or even for solo projects, having source control management system (SCMS) is imperative. There are several popular systems like CVS, SVN, Git, Mercurial, Bazaar etc. the most popular one currently is Git.
There are several very sensible reasons for adopting a source control systems. Most importantly, it allows you to work on your project in small chunks. If things do wrong, you can rollback to the previous good version. Also, you can take advantage of branching and work on two things in parallel. Say, work on a long term feature while doing bug fixes on the currently released version at the same time.
There are several very sensible reasons for adopting a source control systems. Most importantly, it allows you to work on your project in small chunks. If things do wrong, you can rollback to the previous good version. Also, you can take advantage of branching and work on two things in parallel. Say, work on a long term feature while doing bug fixes on the currently released version at the same time.
Command commands
Make sure you are familiar with commands to do the following things in your favourite SCMS:
- Revert the codebase to an older state (you realised you committed bad code and your earlier thing worked much better)
- Clearly see who put in which line of code, when was it added and the associated commit message. It can help you fix a bug or at least put the blame correctly
- You can create a branch, commit to it and deploy out of. This allows you to separate stable stuff from experimental new feature development
Workflow
Once you are familiar with your SCMS, you will have to develop a protocol within you team on how you manage your codebase. This is my favourite workflow using Git:
👉 When a project is in the initial development mode, every one codes in one common branch, "master" (also named "main" some times). Everyone checks in there. It is simple although it is haphazard since commits are mixed in.
👉 After the first release, the master branch is sacrosanct. Checking some code in master means: "this code is good enough to be deployed to the production server right away." Whether you commit directly in master or merge a branch into master, this rule must be followed. Basically, it means no untested or experimental code can be committed into master. While it is used for minor and urgent bug fixes.
👉 All feature development is done in separate branches. Each feature in its own branch. We keep merging master into the development branches. When that branch is ready, it is deployed on staging. PM or Client can test and confirm and then it is merged into master and deployed to production.
Note:
👉 When a project is in the initial development mode, every one codes in one common branch, "master" (also named "main" some times). Everyone checks in there. It is simple although it is haphazard since commits are mixed in.
👉 After the first release, the master branch is sacrosanct. Checking some code in master means: "this code is good enough to be deployed to the production server right away." Whether you commit directly in master or merge a branch into master, this rule must be followed. Basically, it means no untested or experimental code can be committed into master. While it is used for minor and urgent bug fixes.
👉 All feature development is done in separate branches. Each feature in its own branch. We keep merging master into the development branches. When that branch is ready, it is deployed on staging. PM or Client can test and confirm and then it is merged into master and deployed to production.
Note:
- Branches should always be created per feature. No branches by server name or developer name etc. That allows you to decide to release or not release a feature, delay something if required, etc.
- In web applications, there needs to be only one "production" branch ever so having "master" serve as the production release branch works. In other projects, where software is downloaded and installed locally, this strategy will not work and you will need multiple release branches.