Practice and addendum of the most basic branch management mode in Agile Development

For details about how to develop the three branches, see my other article <Analysis of the most basic branch management mode in Agile Development>; 3 branch mode:

If you and your development team are faced with the following problems at the same time, I strongly recommend that you consider using at least three branch development models:

· You only use one or two branches for development.

· Your project has entered the maintenance phase, that is, the project itself has been put into use.

· The user has made many changes in the future, and there will still be sudden emergency error fixes.

· Your code can be released only after being tested by testers.

· Your publisher simply packs and releases existing branches.

If your project team has the above problems, you may be in a very bad situation as an online project. Each release may cause unpredictable damage to the original system; however, it is obviously impossible to release any changes. To continuously meet the requirements of customers, the system must be upgraded. To minimize the impact of each release on the system, 3. The branch solution is the most basic solution.

It is not difficult to adopt a three-branch development model. First, let's assume that your project team has the following three roles (not necessarily three ):

Developer

Testing personnel

Released

How to generate3Branch:

First, confirm that the code of the current version is consistent with the content of the current system.

Name the current branch as the Main branch)

2 branches are separated from the trunk Branches, named "Development" and "Release" respectively)

Define the branch owner: developers are responsible for the Development Branch, testers are responsible for the trunk branch, and publishers are responsible for the release branch.

How to Use3Branch

VDevelopers

Developers can develop the current version on the Development Branch and check the code at will. Note that the version submitted for testing cannot be modified on the Development Branch.

The specified error code can be modified on the trunk branch and checked in only when the developer is notified to fix the error.

Ø developers can fix urgent errors on the Production Branch only when they are permitted by the release personnel. Note that emergency fixes are usually urgent and minor. If the changes are large, you should consider entering version development.

If a developer thinks that a development version has ended, the developer has the right to merge the existing Code of the Development Branch into the master branch and submit the test. (there is only one special case, that is, if the previous version has not been tested and released, the next version cannot be merged into the main branch. This is a mistake in project management and is not covered in this article)

VTester

The tester has the right to have the developer fix the error on the trunk after testing.

The tester needs to regularly merge the master branch code into the Development Branch (this step seems simple, but it is very important !)

After passing the test, the tester can merge the master branch into the production branch and hand it over to the release personnel for release.

VPublisher

Release personnel can allow developers to directly fix emergency errors on the release branch.

After urgent repair, the publisher must completely merge the Production Branch into the main branch.

The publisher can compile the Production Branch and create the release version.

 

However, it is impossible to achieve smooth sailing during development. Emergencies and temporary changes often occur. In the face of various emergency situations in development, how should we use multi-branch development to reduce the risk of temporary changes. (In addition, when dealing with certain special events, the Code merging Technology for the modification set must be used to solve the problem, but the merging problem is unpredictable, this is also a risk that must be faced when a temporary change occurs .)

 

Special scenarios	Solution
Urgent release of tasks in Development versions	Development quality cannot be guaranteed, which is extremely unfavorable to system stability. We recommend that you wait until the test phase before updating.
Urgent release of tasks in beta version	The premise is that the task has passed the test, and then the modification set related to the task is separately merged into the release branch, and then the urgent release system
Task canceled in development version	Rolls back the modification set corresponding to the task. If it overlaps with other code, the merge problem is solved.
Task canceled in beta version	The same method is used for rollback, but after rollback, the Code must be merged back to the Development Branch.
Tasks in the development version are extended.	At the end of version development, replace the latest version with the set modification method. In this way, all the modification sets except this task are merged to the main branch, and the remaining modification sets are moved to the next version.
Task extended in beta version	Similar to the above method, when the version code is merged to the Production Branch, the modification set corresponding to the task is skipped, and the remaining modification sets are merged into the production branch for release respectively, skipped changes are saved to the next version for submission.
Urgent error repair canceled	Roll back the urgent repair code. If the repair Code has already been merged back to the trunk branch, you also need to merge the rollback code back to the trunk branch. Of course, you can merge the code regularly, it will also be merged back to the Development Branch.