Source code branch management method for multiple release versions of railway software

A source code branch management method for multiple release versions of railway software, wherein source code branches comprise a master branch, a feature branch, a hot fixing branch, release branches and production branches, and the master branch is configured to record and store source codes;

• the feature branch is configured for feature development of new functions of the software and bug fixing work;
• the number of the release branches is multiple, and the release branches comprise a general release branch oriented to a general software version and customized release branches oriented to personalized software versions, and are configured for preparation work of software release;
• the number of the production branches is multiple, and the production branches comprise a general production branch oriented to the general software version and customized production branches oriented to the personalized software versions and are configured to deploy and release the software to a production environment;
• the hot fixing branch is configured to emergently fix a bug on the production branch;
• the source code branch management method for multiple release versions of railway software comprises:
• step S1:
• based on the software to be added with a feature, creating a corresponding feature branch according to the requirement of adding the feature, developing the source codes on the feature branch, and obtaining the source codes after the development is completed;
• step S2:
• performing self-testing and review on the developed source codes, and if the self-testing and the review are passed, merging the source codes to the corresponding release branch;
• and if the self-testing or the review is not passed, returning to the step S1;
• step S3:
• performing system integration testing and function testing on the source codes merged into the release branch, merging the release branch into the corresponding production branch if the integration testing and the function testing are passed, and meanwhile, if the source codes on the general release branch pass the integration testing and the function testing, also merging the source codes on the general release branch into the master branch for storage and submitting the source codes to each customized production branch from the master branch;
• if the integration testing or the function testing is not passed, returning to the step S1;
• step S4:
• performing automatic code construction, packaging and storage on the source codes on the production branch to obtain an artifact;
• step S5:
• performing acceptance testing on the artifact, and if the acceptance testing is passed, formally releasing the software corresponding to the artifact;
• if the acceptance testing is not passed, rolling back the merging operations in the step S2 and the step S3 on the production branch, and returning to the step S1;
• and
• step S6:
• continuously monitoring a state of the software which is formally released, and when the software has unexpected failure in a running process and the source codes need to be modified, creating the hot fixing branch from the corresponding production branch, emergently fixing the artifact by using the hot fixing branch, returning to the step S2, and performing the self-testing and the review by taking the emergently fixed source codes as the source codes.