Selamat siang semuanya!
Perusahaan kami mengembangkan perangkat lunak untuk sektor publik dan terus-menerus mengesahkan programnya untuk memproses pemerintah. rahasia. Dan ini memberlakukan batasan tertentu dan yang paling penting di antaranya: kita harus menyediakan semua kode sumber untuk proyek kita dan, jika diminta, dapat menjelaskan apa yang dilakukan setiap baris. Masalahnya adalah jika Anda menggunakan komponen yang sudah jadi, maka kode sumbernya juga harus disediakan dan dapat memberi tahu segalanya tentang mereka. Oleh karena itu, kami memutuskan untuk membuat kerangka kami sendiri, karena kami akan tahu segalanya tentang itu. Kami membuat kerangka kerja dan menamakannya "Platform". Itu terus berkembang dan kami melakukan semua proyek kami di atasnya. Masalahnya adalah, setelah rilis produk dan pengirimannya, kami harus membekukannya dan tidak dapat membuat perubahan besar padanya - hanya memperbaiki bug,dan sebagian besar bug ditemukan dalam kerangka itu sendiri, dan sebagai hasilnya, kami terpaksa memiliki versi kerangka kerja untuk setiap proyek yang dikirimkan (baik, atau untuk sekelompok produk yang dirilis secara bersamaan). Akibatnya, kami harus membuat seperangkat aturan kami sendiri dan skema percabangan di GIT untuk mengembangkan Platform. Diagramnya ditunjukkan di bawah ini bersama dengan contoh cara kerjanya:
Aturan umum untuk proyek percabangan:
1. Konsep berikut telah diperkenalkan:
Sebuah. Versi utama program - versi program dalam kerangka konsep tertentu, berubah dengan perubahan konsep yang signifikan, dilambangkan dengan vm, di mana m adalah nomor versi utama;
b. Versi minor dari program ini adalah subversi dalam konsep yang sama, berubah ketika fungsi baru ditambahkan atau yang sudah ada sedikit diubah, dilambangkan dengan vmn, di mana m adalah nomor dari versi mayor, n adalah jumlah minor Versi: kapan;
c. Rilis program - versi dari versi minor, nomor rilis berubah dengan perubahan kecil dan / atau perbaikan bug dalam versi minor yang sesuai dari program, dilambangkan dengan rmnp, di mana m adalah nomor versi mayor, n adalah nomor versi minor, p adalah nomor patch;
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.