Do you continue development in a branch or in the trunk? [closed]

Answer 1

The trunk is generally the main development line.

Releases are branched off and often times experimental or major work is done on branches then merged back to the trunk when it's ready to be integrated with the main development line.

Answer 2

Both.

The trunk is used for the majority of development. But it's expected that best efforts will be made to ensure that any check-in to the trunk won't break it. (partially verified by an automated build and test system)

Releases are maintained in their own directory, with only bug fixes being made on them (and then merged into trunk).

Any new feature that is going to leave the trunk in an unstable or non-working state is done in it's own separate branch and then merged into the trunk up on completion.

Answer 3

I like and use the approach described by Henrik Kniberg in Version Control for Multiple Agile Teams. Henrik did a great job at explaining how to handle version control in an agile environment with multiple teams (works for single team in traditional environments too) and there is no point at paraphrasing him so I'll just post the "cheat sheet" (which is self explaining) below:

I like it because:

• It is simple: you can get it from the picture.
• It works (and scales) well without too much merge and conflict troubles.
• You can release "working software" at any time (in the spirit of agile).

And just in case it wasn't explicit enough: development is done in "work branch(es)", the trunk is used for DONE (releasable) code. Check Version Control for Multiple Agile Teams for all the details.

Answer 4

I've worked with both techniques and I would say that developing on the trunk and branching off stable points as releases is the best way to go.

Those people above who object saying that you'll have:

• Constant build problems for daily builds
• Productivity loss when a a developer commits a problem for all other people on the project

have probably not used continuous integration techniques.

It's true that if you don't perform several test builds during the day, say once every hour or so, will leave themselves open to these problems which will quickly strangle the pace of development.

Doing several test builds during the day quickly folds in updates to the main code base so that other's can use it and also alerts you during the day if someone has broken the build so that they can fix it before going home.

As pointed out, only finding out about a broken build when the nightly build for running the regression tests fails is sheer folly and will quickly slow things down.

Have a read of Martin Fowler's paper on Continuous Integration. We rolled our own such system for a major project (3,000kSLOC) in about 2,000 lines of Posix sh.

Answer 5

We develop on the trunk unless the changes are too major, destabilizing, or we are nearing a major release of one of our products, in which case we create a temporary branch. We also create a permanent branch for every individual product release. I found Microsoft's document on Branching Guidance quite helpful. Eric Sink's tutorial on branching is also interesting, and points out that what works for Microsoft may be too heavy for some of the rest of us. It was in our case, we actually use the approach Eric says his team does.