Path to version management in parallel development (II)-typical version management challenges

Previous Article: Path to version management in parallel development (I) --- version management crisis

After reading the previous article, we should have a basic understanding of the problems that are easily caused by multi-branch development. In fact, Version Management in parallel development usually faces the following typical challenges:

1. How can I ensure that the new version is developed at the same time as the BugFix? That is, bugs that have been modified cannot exist in the new version.
2. How to ensure parallel development of two new versions? It may be two completely different versions, or one is another foundation.
3. How can we ensure that the release of a version is not affected by the unintentional code check?

    

    

The answer to these three challenges is to use the branch (Here we design a famous version management tool-ClearCase, which is an important tool and concept ).

 

[OK, here is a term, that is, Branch. To understand a branch, you must understand other terms, such as labels and views. This document does not describe the basic concepts in detail. For more information about these concepts, see the documentation of ClearCase (a powerful version management tool).]

`
 

The above is a version tree that visually records the version changes of a file.

1. versions 1, 2, and 3 are different,
2 Main, Ver2.0 is the branch.
3 Release1023 and Ver2.0Begin are tags, which are like tags on the code version.
4. The view is the code cross section determined by the branch type, tag name, and dynamically obtained rules. I can create a Main branch view. In this view, I cannot see any code modifications in the Ver2.0 Branch. I can also create a Ver2.0 branch view, in this view, we can see the latest code of the Ver2.0 Branch and the code in the Ver2.0Begin label of the Main branch that has not been modified in the Ver2.0 branch. Developers are always used to working on a view.

 

OK, then let's look at the solution to the first problem.

 

1. Create a branch view for modifying bugs and modify it on this view
2. Merge the modified Code on the BugFix to the master branch, and generate a new version 3. Move the Ver2.0Begin tag to version 3. Ver2.0 automatically obtains the code after fixing the BUG, the BUG on the main branch is also corrected.
3. If the Code has changed on Ver2.0 at this time, you need to execute another merge to merge the changes into Ver2.0. Fortunately, Ver2.0 code is not modified most of the time before the BugFix.

In doing so, we have gained at least a few additional benefits.

1. We have gained the ability to publish stable versions from the Main branch.
2. We have gained the ability to release the latest preview version from the Ver2.0 branch.
3. Check and check by developers does not affect version release
4. The version administrator can lock the Main branch to prevent unauthorized or accidental modification of the code of the Main branch.

To be continued ......