Introduction to the
In this paper, simulating the SVN branch management records, the main reference design approach: www.cnblogs.com/huangjinyon…
Strategy description
Branch life cycle
Dev mainline development branch, basically a branch, will not play multiple
Branch the feature according to the small functions required, and delete it after merging
Qa, test branch, merge every time you send a package, only need one branch
Pro_cortp main branch, which is merged by the branch after the test is done. Only one branch is required
Release requires multiple branches to mark the release, which is a waste of space
Fixbug, bug repair branch, according to the bug repair branch, finally merged after deletion
layout
Trunk (historical branch)
The branch where the basic environment code is stored at the beginning of the project. In general development projects, a branch is set up after the environment required by the tools required for development is defined. It faces developers and is equivalent to an internal version release branch
Test branch
At the beginning of the project, a test branch is created based on the history branch pro_ CORTP
Note: The first operations, such as creating branches and merging branches, are described here, and the subsequent repeated operations are not described
The branch created in this way is directly in the cloud repository to create the corresponding branch, remember to update the operation
Development mainline branch
The development mainline branch is created directly from the test branch. It might be easier to understand why it is created from the test branch.
If you think about it, the main branch is separated from the test branch, so when the main branch is developed and merged back into the test branch, there is no conflict. What do you think is the reason?
Yes, since the main branch is created from the test branch, and the main branch is always under development and has a higher version number than the test branch, merging back into the test branch is actually an update operation for the test branch. It is also important to note that merging requires an ancestral relationship.
Development branch
This branch actually flexibility is very big, can even do not use the branch, based on the main branch of development directly, but you need to function or some other way can be defined for the unit to define the development of the whole project, you can use to the branch, it will make you look more organized project development process.
The development of
Now everything is ready to start the development, according to the project, divide the corresponding development line branch, development branch, each person receives the task to develop, submit, when the development of a stage is almost the same, we have to start the branch management most dreaded step, branch merge.
Merge between development branches
Merge is indeed a difficult thing to understand, but in fact, there is no need to fear, as long as follow my recommended merge method, can be bold merge attempt, anyway, can be restored.
Note: Commit multiple branch changes for a single version is prohibited! SVN is actually a version manager. If you change multiple branches of code in a version, you may encounter undesirable results during the merge, such as no changes in the merged code.
Tortoise SVN (Tortoise SVN
Why not use the SVN built-in with IDEA?
SVN in IDEA I did not find the merge of version range, can only merge two trees, so I do not recommend it
Here is the directory structure to be merged from feature to dev:
Among them, the description file is a conflict problem, I have modified the content, the other two different name files on behalf of the main line development and branch development of different function to achieve the code, now start to merge the operation explained
Select the home directory that you want to merge.
Select version range merge
If you select the branch directory to be merged, you can find that the merge source is obtained from the remote end. Therefore, the merge source does not need to exist on the local end. However, you are advised to update the local directory to the latest version consistent with the remote end before merging
It is recommended to use a test merge to see what happens
There is obviously a conflict, double-click the corresponding conflict to resolve it
When the resolution is complete, you discover that the merged code is actually uncommitted
Yes, this kind of merge is actually merge to the local, can be restored at any time before submission, just need to execute the code after the merge, test whether there is a problem with the merge project can be submitted, if there is a problem can be reversed operation, to eliminate the cause of the problem
Test the merge of branches
When the development is completed, the package test needs to be carried out. In fact, the test directory is used as the main trunk to merge the development branch, and since the files in the test branch are used for testing, there will be no modification, this merge is equivalent to the version update of the test branch, without any conflict
After testing, merge the history branches
Here to merge and merge test branch, because the test branch from the branches of history, working in the branch to complete testing to determine the current version to recorded history on the branch, have a history, also is given priority to with historical branch, branch consolidation test, it also belongs to the updated version, for history branch will not conflict
Release online version
In this stage, the online version branch is actually to create a release branch based on the historical branch. It should be noted that it is suggested to record the version of each online version (i.e. create the branch). Although it will waste space, the version record in the form of milestone can be achieved.
Online Bug fixes
There are actually two ways to deal with online bugs. If the bugs are not particularly urgent, it is suggested to create a new feature branch on the main line development branch to deal with them and wait for the unified repair in the subsequent version update.
On the other hand, if it is an urgent bug, you can print a fixbug branch based on the release branch, deal with this bug separately, and merge it back to the current online version after processing, and must merge it back to the mainline development version, as for the history branch can wait for the mainline development of the next historical version after merging.
conclusion
Above as the basic framework of constructing and using SVN branch management mode, it can be seen that branch merge as long as follow the planning of their duties, each branch is located in the merger between father and son branch branch or ancestors in order, you can do an orderly development process, only when making an emergency bug fixes will appear across generational merge operations.
Dog’s life
I am in the internship stage, the above is some summary after sorting out the materials and their own operation, if there is any mistake, welcome to correct