Guten Tag allerseits!
Unser Unternehmen entwickelt Software für den öffentlichen Sektor und zertifiziert ständig seine Programme zur Verarbeitung durch die Regierung. Geheimnisse. Und dies bringt bestimmte und die wichtigsten Einschränkungen mit sich: Wir müssen alle Quellcodes für unser Projekt bereitstellen und auf Anfrage erklären können, was jede Zeile tut. Das Problem ist, dass bei Verwendung vorgefertigter Komponenten auch deren Quellcode bereitgestellt werden muss, um alles über sie zu erzählen. Deshalb haben wir uns entschlossen, unser eigenes Framework zu erstellen, weil wir alles darüber wissen werden. Wir haben ein Framework erstellt und es "Plattform" genannt. Es entwickelt sich weiter und wir machen alle unsere Projekte darauf. Das Problem ist, dass wir das Produkt nach der Veröffentlichung und seiner Lieferung einfrieren müssen und keine größeren Änderungen daran vornehmen können - nur Fehler beheben,Die meisten Fehler sind im Framework selbst zu finden. Daher müssen wir für jedes eingereichte Projekt (naja oder für eine Gruppe gleichzeitig veröffentlichter Produkte) Versionen des Frameworks haben. Infolgedessen mussten wir in GIT eigene Regeln und ein Verzweigungsschema für die Entwicklung der Plattform entwickeln. Das folgende Diagramm zeigt ein Beispiel für die Funktionsweise:
Allgemeine Regeln fĂĽr Verzweigungsprojekte:
1. Folgende Konzepte wurden eingefĂĽhrt:
ein. Hauptversion des Programms - Die Version des Programms im Rahmen eines bestimmten Konzepts ändert sich mit wesentlichen Änderungen des Konzepts, bezeichnet mit vm, wobei m die Nummer der Hauptversion ist.
b. Die Nebenversion des Programms ist eine Subversion innerhalb desselben Konzepts, die sich ändert, wenn eine neue Funktionalität hinzugefügt oder eine vorhandene geringfügig geändert wird. Dies wird mit vmn bezeichnet, wobei m die Nummer der Hauptversion und n die Nummer der Nebenversion ist Ausführung;
c. Programmversion - eine Version einer Nebenversion, deren Versionsnummer sich mit geringfügigen Änderungen und / oder Fehlerkorrekturen in der entsprechenden Nebenversion des Programms ändert, bezeichnet mit rmnp, wobei m die Hauptversionsnummer ist, n die Nebenversionsnummer ist, p ist die Patchnummer;
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.