Branching Patterns / Policies

Question

Now I am updating the version control method of our store. We will use a server-oriented versioning solution.

I would like to see other people branch out and successfully cope without all the headaches I read about.

What are some field-proven field patterns that you saw in a working environment that worked well, i.e. branching for release. What policies were created to ensure a smooth branch transition.

thanks

Answer 1

It depends on what kind of software you are developing.

We are an online store for us, so we do not have numbered "releases". We keep our luggage as the fact that “production” is worthy and only directly makes small changes.

When we have a large project, we create a branch and process it until it is ready for production, all the time synchronizing the trunk in it.

If the project involves a major restructuring of the code base, we usually create the tag in the last revision before merging the branch changes.

Again, if you create packaged software where you need to support different versions, this will not work much the same.

For the record we use Subversion .

Answer 2

the subversion book describes some commonly used branch patterns (e.g. release branches, function branches, etc.).

Answer 3

3 things when considering branching.

First: branching is ok if you are going to combine things again. Of course, you can always have a branch with a specific patch for one of your clients with a specific problem. But in the end, you want to combine most of the patches back into the main trunk.

Second: confirm your needs. I saw a tree of all sizes depending on the size of the department, the number of customers, etc.

Third: check how good your source of control is for branching and merging. For example, CVS is known to be very poorly suited for this type of operation. SVN, “CVS done right,” they say, is a little better. But Linus Torvalds, who created Git (which is especially good for this kind of operation), will tell you that CVS cannot be done correctly (he said this in a very interesting presentation on Git). Therefore, if you have a real need for branching and merging, at least get SVN, not CVS.

Answer 4

Look at the branching patterns:

http://www.cmcrossroads.com/bradapp/acme/branching/

It describes a number of templates for working with templates. I usually worked in two ways:

• Stable receiving line - all developments are carried out in branches and integrated into the trunk only when necessary. This means that you always have one stable release point.

• The main line of development - all work is carried out in the trunk. When it comes to release, you take the release tag and use it. If a large experimental alteration is required, it is carried out in a branch and, with a stable combination, back to the trunk.

Answer 5

This is the way we do, and it works well for us ...

Project | +--01-Development | | | +--Release1.0 | | | | | +--Solution Files | | | +--Release2.0 | | | +--Solution Files | +--02-Integration | | | +--Release1.0 | | | | | +--Solution Files | | | +--Release2.0 | | | +--Solution Files | +--03-Staging | +--04-Production 

well, you get the point ...

NOTE. . The directory structure in the Team Foundation Server branches exists only between 01-Development / Release1.0 and 02-Integration / Release1.0, 02-Integration / Release1.0 and 03-Staging / Release1.0, 03-Staging / Release1.0 and 04-Production / Release1.0

In other words, you cannot combine 03-Staging / Release1.0-04-Production / Release2.0, etc.

For us, this means that we have 4 separate environments: development, integration (alpha server), stage (beta server), production.

The beginning of the code begins with development, and then advances as it is tested by QA (integration / alpha) and users (stage / beta) and, finally, into production.

Features / changes are collected and grouped into releases that occur every few months.

But let's say that you are in development for Release2.0, and you get a production problem on Release1.0 ... I can easily get the latest version of Release1.0 and fix the problem and promote it without any action, we worked on Release2. 0

Not to say that it will work for everyone in any situation, but it is very good for us.