Explain Trunk, Branch, Tag And Related Concepts

Trunk, Branch and Tag concepts are relevant to revision control (or version control) systems. These systems are typically implemented as repositories containing electronic documents, and changes to these documents. Each set of changes to the documents is marked with a revision (or version) number. These numbers identify each set of modifications uniquely.

Reminder

A version control system, like Subversion, works with a central repository. Users can check out its content (i.e., the documents) to their local PC. They can perform modifications to these documents locally. Then, users can commit their changes back to the repository.

If there is a conflict between modifications made to documents by different users committing simultaneously, Subversion will ask each user to resolve the conflicts locally first, before accepting their modifications back to the repository. This ensures a continuity between each revisions (i.e., set of modifications) made to the content of the repository.

What is this good for? If the repository is used to store software development code files, each developer can check-out these files locally, and after making modifications, they can make sure these compile properly before committing their modification back to the repository. This guarantees that each revision compiles properly and that code does not contain any incoherence.

In other words, this enables the implementation of Continuous Integration of software engineers' work in the same code base.

Trunk, Branches & Tags

Sometimes, software development requires working on large pieces of code. This can be experimental code too. Multiple software developers may be involved. These modifications are so large that one may want to have a temporary copy of the repository content to work on, without modifying the original content. This is issue is addressed with trunk and branches.

When using Subversion, the typical directory structure within the repository is made of three directories: trunk, branches and tags. The trunk contains the main line of development. To solve the issue raised above, a branch can be created. This branch is a copy of the main line of development (trunk) at a given revision number.

Software developers can check the branch out, like they would with trunk content. They can perform modifications locally and commit content back to the branch. The trunk content will not be modified. Multiple software developers can work on this branch, like they would on trunk.

Once all modifications are made to the branch (or experimental code is approved), these modifications can be merged back to trunk. Just like with a simple check-out, if there is any incoherence, Subversion will request software developers to solve them at the branch level, before accepting to merge back the branch into trunk.

Once the branch is merged, it can also be closed. No more modification on it is accepted. Multiple branches can be created simultaneously from trunk. Branches can also be abandoned and deleted. Modifications are not merged back to trunk.

When the software development team has finished working on a project, and every modifications have been committed or merged back to trunk, one may want to release a copy (or snapshot) of the code from trunk. This is called a tag. The code is copied in a directory within the tag directory. Usually, the version of the release is used as the directory name (for example 1.0.0).

Contrary to branches, tags are not meant to receive further modifications. Further modifications should be performed only on trunk and branches. If a released tag need modifications, a branch from the tag (not the trunk) should be created (for example, with name 1.0.x). Later, an extra tag from that tag branch can be created with a minor release version (for example 1.0.1).

Why work like this? Imagine a software application is released and put on production (version 1.0.0). The team carries on working on version 2.0.0 from trunk (or a branch from trunk). This makes sense regarding the continuity of the code line. Later, one finds a bug on version 1.0.0. A code correction is required. It cannot be performed on trunk since it already contains 2.0.0 code. Tag 1.0.0 must be used. Hence, the need to create a branch from tag 1.0.0.

But what about the code correction created for the 1.0.0 bug? Shouldn't it be included in version 2.0.0? Yes, it should, but since branch 1.0.x cannot be merged back to trunk (it comes from tag 1.0.0), another solution is required. Typically, one will create a patch containing the code correction from branch 1.0.x, and apply it locally from a check out of trunk. Then, this code correction can be committed back to trunk and it will be part of version 2.0.0.

Branches created from tag releases have a life of their own. They are called maintenance branches and remain alive as long released versions are maintained. Contrary to trunk branches, they are never merged back with their original tag. You could consider them like little trunks for tag releases.