daniel fäldt

No matter which version control system (VCS) you are using in your software development environment is is important to have a strategy for working with branches, trunk and tags.

One of the most convenient way is to follow the “branch always” strategy. Do never ever do development on the trunk*! This, together with a trunk integration policy, will cause the trunk always being “compilable“. It will also help the developer a lot since she can use the VCS as a VCS, thus check in things whenever she wants or whenever it helps her.

Example:

Every time the developer have produced something useful, good or at least something to remember. She should do a commit! The VCS keeps the history for you and you can do more “crazy” things since you know you always can get back to what it was like before (and all steps in between where you have done a commit). Thus, do commits often into your own temporary development branch!

Step by step:

1. You got an story to develop.
2. Do a temporary branch for your development and switch to it.
3. Do some development and commit your changes to your branch.
4. Do some more development and commit.
5. Do an update from trunk and merge it into your branch.
6. If story implementation isn’t finished, goto step 4.
7. Implementation finished. Do a last update of your branch.
8. Test your functionality again so you are sure it is really working.
9. Integrate (merge) your implementation into trunk.
10. Delete your temporary branch.
11. Goto step 1.

This is especially good when working in an agile environment since the idea is that the code (trunk), at all time, should be compilable and runnable.

What’s the down side?

The developer need to know how to use a VCS, which means how to branch, merge, update etc. Since this really is an important tool for a developer this should not cause any oppositions at all.

For the lazy developer there can be oppositions in the beginning though since there is actually some extra work to do, it is not just coding. It is much easier (for that single person) to just work onto trunk.

When everyone works on trunk it means that everyone gives everyone the problems on every commit. It also means that the developer doesn’t have any upsides of using the VCS, it is just a matter for the configuration managers. A VCS is a development tool first! For developers needs! They just have to understand that they need it.

Trunk integration policy

As mentioned above there also need to be a trunk integration policy. This policy is really simple. Do not integrate/merge anything into trunk if it isn’t working (compiling, running) in your development branch. Always do an update before integrating to trunk to avoid merge problems (and new compile/run problems caused by merging).

(*) There is a few exceptions to this, minor bugfixes can be made directly on to the trunk, if the impact is very small and there is no new logic in it.