Good day everyone!
Our company develops software for the public sector and constantly certifies its programs for processing government. secrets. And this imposes certain restrictions and the most important of them: we must provide all the source codes of our project and, if asked, be able to explain what each line does. The problem is that if you use ready-made components, then their source code must also be provided and be able to tell everything about them. Therefore, we decided to make our own framework, because we will know everything about it. We made a framework and named it "Platform". It continues to develop and we do all our projects on it. The problem is that, after the release of the product and its delivery, we have to freeze it and cannot make major changes to it - only fix bugs,and most of the bugs are found in the framework itself, and as a result, we are forced to have versions of the framework for each delivered project (well, or for a group of simultaneously released products). As a result, we had to come up with our own set of rules and a branching scheme in GIT for developing Platform. The diagram is shown below along with an example of how it works:
General rules for branching projects:
1. The following concepts have been introduced:
a. Major version of the program - the version of the program within the framework of a certain concept, changes with significant changes in the concept, denoted by vm, where m is the number of the major version;
b. The minor version of the program is a subversion within the same concept, changes when a new functionality is added or an existing one is slightly altered, denoted by vmn, where m is the number of the major version, n is the number of the minor version;
c. Program release - a minor version, the release number changes with minor changes and / or bug fixes in the corresponding minor version of the program, denoted by rmnp, where m is the major version number, n is the minor version number, p is the patch number;
2. master. master , merge-request. merge-request (code review).
3. ( ). master, : dev-v-m, m – . master. dev-v-m project_name_dev_v_m. .
4. – , . . :
a. t-xxxxx, (xxxxx – )
b. b-xxxxx, (xxxxx – ).
5. , , .
6. , , , v-1-1 ( , ). master, . master , () .
7. ( ) . – . v-m-n, m – , n – . . , . r-m-n-p, m – , n – , p – ( ). . , . , .
8. , .
9. , .
10. , , .. . master . , , , ( ). , .
11. , .
12. : t-#####-taskname b-#####-bugname.
, . :
01.01.17 C1 master. master . , ( ) . , 1 2 . C1 (t-####) t-1 t-2. (, t-1 t-1-C1 t-1-C2). , , . merge request , .. , , . code review ( ). , merge request , . code review, merge request C2 3. master . , , , .
08.01.17 1-0 v-1-0. v-1-0 . v-1-0 . . b-1 b-3 merge request’ v-1-0. , merge request v-1-0 v-1-0-C1, v-1-0-C2 v-1-0-C3. , , .
master , v-1-1. master .1 , , . , C4, b-2 merge-request master v-1-0, .. .
01.02.17 v-1-0, , . r-1-0-1. . v-1-0 , .. , master.
-1-0-1 b-3 v-1-0 08.02.17 - r-1-0-2. , v-1-1 v-1-1. master v-2-0. v-1-0, v-1-1. b-4, v-1-0 master, .. , , .
04.03.17 r-1-1-1. 1 2. v-1 , (dev-v-1) ( ). dev-v-1 master, v-1. v-1-0, , .. v-1-1.
15.03.17 v-2-0 v-2-0.
18.03.17 v-1 v-1-2.
01.04.17 v-1 (r-1-2-1) v-2 (r-2-0-1). v-1-1, .. v-1-2.