blog

Git filial strategiyasi

NEXTREE.

• 12 min read
Git filial strategiyasi

1. Kirish

Git branchlarini "funksiya bo'yicha ajratish vositasi" deb o'ylash oson, ammo haqiqiy ishda branch strategiyasi hamkorlik usuli, rivojlanish muhitini tarqatish va sinovdan o'tkazish, QA tasdiqlash, operatsion tarqatish, hotfixga javob berish bilan bevosita bog'liq. Bir necha kishi bir vaqtning o'zida rivojlanishi va belgilangan jadvalga muvofiq tarqatilishi kerak bo'lgan muhitda, ayniqsa branch strategiyasi oddiy Git foydalanish qoidalaridan ko'ra jamoaning ishlash uslubi bo'ladi.

Avvaliga Git Flow, GitHub Flow kabi nomlarni asos qilib olib, amaliy branch tuzilishini tushunmoqchi edim. Ammo haqiqiy loyiha boshlanganida branch strategiyalari darsliklar bilan to'liq mos kelmaydi. feature, develop, stage, prod, release kabi branchlar bo'lishi mumkin, ammo haqiqiy ishlash usuli tarqatish davri, QA metodi, odamlar soni, CI/CD muhitiga, tasdiq jarayoniga qarab o'zgaradi.

Ushbu maqolada yetakchi branch strategiyalarini qisqacha tahlil qilgan holda, haqiqatan ham tajriba orttirgan muhit branch va tarqatish nomzod branch strukturasini asos sifatida keltiraman. Ushbu strategiyani to'g'ridan-to'g'ri loyihalashtirmagan bo'lsam-da, feature branch yaratib, rivojlanish branchiga birlashtirib sinovdan o'tkazish va tarqatish nomzod branchiga funksiyalarni yig'ib operatsion tarqatish jarayonida afzalliklar va e'tibor berilishi kerak bo'lgan jihatlarni tushunish imkoniyatiga ega bo'ldim.

Ushbu tajribamda eng muhim narsalardan biri "bizning jamoamiz Git Flow ishlatyaptimi yoki GitHub Flow ishlatyaptimi" degan belgilardan ko'ra, har bir branchning roli aniq ekanmi, birlashtirish yo'nalishi bir xil ekanmi, tarqatish mezonlari va sinkronizatsiya jarayonini jamoa a'zolari bir xil tushunayotganligi yanada muhimroq ekanligini anglab yetishim edi.

2. Yetakchi Git branch strategiyalari

2.1 Git Flow

Git Flow branch rollarini aniq ajratadigan chiqarilish markazida strategiyadir. main yoki avvalgi nomi master operatsion tarqatish mumkin bo'lgan chiqarilish tarixini boshqaradi, develop esa keyingi tarqatish uchun integratsiya branch vazifasini bajaradi. feature/* funksiyalarni rivojlantirish, release/* chiqarilishdan oldin barqarorlashtirish va versiya tayyorlash, hotfix/* esa operatsion tezkor tuzatish uchun ishlatiladi.

feature/* -> develop -> release/* -> main
hotfix/*  -> main, develop 또는 현재 release/*

Aniq versiya chiqarilishlar bo'lsa yoki chiqarilishdan oldin alohida barqarorlashtirish va tasdiqlash bosqichi kerak bo'lsa yoki bir nechta versiyalarni saqlashga mo'ljallangan loyiha uchun juda mos keladi. Biroq branchlar ko'p va birlashtirish yo'nalishlari belgilangan bo'lsa, jamoada qoidalarni bo'lishish, branchni himoya qilish, avtomatlashtirish muhimdir. Har bir loyihaga asos sifatida qo'llashdan ko'ra, chiqarilish usuli va jamoa o'lchoviga mos keladimi, dastlab aniqlanishi lozim.

2.2 GitHub Flow

GitHub Flow main branchiga asoslangan oddiy strategiyadir. Funksiya rivojlantirish qisqa feature branchda olib boriladi va Pull Request orqali ko'rib chiqilib, sinovdan o'tkazilgandan so'ng mainga birlashtiriladi. Asosiy jihat shundaki, mainga kiritilgan kod har doim tarqatishga tayyor bo'lishi kerak.

feature/* -> Pull Request / CI / review -> main -> deploy

Amaliyotda, mainga birlashtirilganda darhol avtomatik tarzda tarqatiladigan jamoalar bo'lib, qo'l bilan tasdiqlash yoki bosqichma-bosqich tarqatish jarayonini o'tayotgan jamoalar ham mavjud. Shuning uchun "mainga birlashtirilganda shartli ravishda darhol tarqatiladi" deganidan ko'ra "mainga birlashtirilgan kod har qanday vaqtda tarqatishga tayyor bo'lishi kerak" deb tushunish yanada to'g'riroqdir.

Oddiy va PR markazidagi hamkorlikka mos keladi, ammo hali foydalanuvchiga ko'rsatilmasligi kerak bo'lgan funksiyalar feature flag, ruxsat nazorati, sozlama qiymatlari, bosqichma-bosqich rollout kabi usulda nazorat qilinishi kerak. main buzilganda tarqatish jarayoni to'xtab qoladi, shuning uchun avtomatik sinovlar va branchni himoya qilish qoidalari ham muhimdir.

2.3 GitLab Flow

GitLab Flow GitHub Flow ning oddiy feature branchdan Merge Request orqali mainga birlashtiradigan jarayoniga asoslanib, loyihaning tarqatish uslubiga qarab production branch, staging branch, release branch, taglar, CI/CD muhitini birlashtirib operatsion jarayonni ifodalaydi.

예시 1: feature/* -> main -> staging -> production
예시 2: feature/* -> main -> release/x.y -> production deploy

Git Flowdan oddiyroq, GitHub Flowdan esa tarqatish va tekshirish bosqichlarini aniq ifodalash imkonini beradi. QA, staging, UAT, production kabi muhitlarning tekshirish bosqichlari muhim bo'lgan loyihalarda foydali.

Ammo GitLab Flow doimo staging yoki production filiallini saqlashni anglatmaydi. GitLab CI/CD ning environment funksiyasi orqali QA, staging, production muhitlarini boshqarish mumkin, shuningdek, release filiali yoki tag asosidagi tarqatishni tanlash mumkin. Ya'ni, muhit filiali GitLab Flow ning asosiy shakllaridan biri, lekin majburiy shart emas.

2.4 Trunk-Based Development

Trunk-Based Development bir markaziy filialga, odatda main yoki trunk ga tez-tez o'zgarishlarni birlashtirish strategiyasidir. Filiallardan umuman foydalanmaslikni anglatmaydi, balki uzoq muddatga saqlanayotgan filiallardan qochish va kichik unitdagi o'zgarishlarni qisqa filial yoki to'g'ridan-to'g'ri commit urish usuli bilan tezda birlashtirish asosiy maqsaddir.

main 또는 trunk
└─ short-lived branch -> main 또는 trunk

trunk doimo qurilish imkoniyatiga ega bo'lishi kerak, shuning uchun tez CI, avtomatik sinovlar, kichik ish birliklari, tez kod ko'rib chiqish muhimdir. Katta funksiyalarni bir marta uzoq vaqt yashirishdan ko'ra, feature flag, branch by abstraction, konfiguratsiya boshqaruvi kabi vositalardan foydalanib, tugallanmagan funksiyalarning foydalanuvchilarga ko'rsatilmasligini ta'minlash kerak.

Tez-tez CI/CD yaxshi o'rnatilgan va avtomatik testlarga ishoniladigan tashkilotlarga mos keladi. Aksincha, testlar sekin yoki qo'lda tekshirishga yuqori darajada bog'langan va funksiyalarga mo'ljallangan filiali uzoq davom etadigan tashkilotlarda trunkni barqaror saqlash qiyin.

3. Amaliyotda standart strategiya to'liq qo'llanilmaydi

Amaliy loyihalarda bitta strategiyaning mukammal qo'llanilishi o'rniga, ko'pincha bir nechta strategiya elementlari aralashadi. Filial strategiyasi oddiygina Gitdan foydalanish usuli emas, balki tarqatish davri, QA usuli, boshqaruv muammolariga javob berish, jamoa a'zolari, CI/CD darajasi, ish tasdiqlash jarayoni kabi ko'plab omillar bilan bog'liq.

Masalan, develop, stage, prod filiallari bor deb, hech qanday Git Flow ni anglatmaydi. Staging yoki production filiali bor deb, doimo GitLab Flow deb xulosa qilish mumkin emas. Main dan feature filialini olsangiz va yana main ga birlashtirsangiz, bu hech qanday Trunk-Based Development ga aytilmaydi. Pull Requestdan foydalansangiz, bu GitHub Flow ga aylanmaydi. PR filial strategiyasining o'zi emas, balki kodni ko'rib chiqish va birlashtirish uchun hamkorlik usulidir.

Amaliyotda filial strategiyasini tushunganingizda, nomdan ko'ra quyidagi savollarga javob bera olish muhimroq edi.

  • Amaliy tarqatish uchun asosiy filialni nima ekanligini aniqlash kerak.
  • Rivojlantirish va tekshirish uchun tarqatiladigan filiallar har birida nima ekanligini aniqlash kerak.
  • feature filiallari qayerda yaratiladi va qayerga birinchi bo'lib birlashtirilishini aniqlash kerak.
  • Ushbu tarqatishga kiritiladigan feature qanday tanlanishini aniqlash kerak.
  • Amaliy tarqatilishidan so'ng rivojlantirish/tekshirish filiallari qanday sinxronlanishini aniqlash kerak.
  • hotfix qaysi branchdan boshlanadi va qaysi branchga qaytarilishi kerakligini aniqlash kerak.

Bu savollarga javoblar aniq bo'lganda, jamoa a'zolari bir xil me'yor asosida harakat qila oldi. Aksincha, branch nomi tanish bo'lsa-da, asl roli noaniq bo'lsa, rivojlanish branchiga kirgan funktsiyalarning barchasi tarqatiladimi yoki tasdiqlash branchi ishga tushirish uchun nomzodmi yoki oddiy test uchunmi kabi jihatlarda noto'g'riliklar paydo bo'lishi mumkin edi.

4. Amaliy tajriba: muhit branchi va tarqatish nomzod branchi tuzilishi

Men tajriba qilgan loyihalarda ishga tushirish branchi, rivojlanish branchi, va tasdiqlash branchi mavjud edi. Asl branch nomlari loyihadan loyihaga farq qilishi mumkin, shuning uchun bu maqolada nomdan ko'ra rolga asoslanib tushuntiraman.

  • Ishga tushirish branchi asl xizmat ko'rsatish tarqatishining mezoni bo'lgan branchdir. Odatda, himoyalangan branch sifatida o'rnatilib, to'g'ridan-to'g'ri push cheklanadi.
  • Rivojlanish branchi rivojlanish tarqatishi va birlashtirilgan test uchun branchdir. Buni ishga tushirish tarqatishidagi barcha narsalarni anglatmaydi.
  • Tasdiqlash branchi QA, staging, pre-production va boshqa ishga tushirish oldi tasdiqlash muhitlariga tarqatiladigan branchdir.
  • feature branchi individual ish uchun mo'ljallangan branchdir. Tanlangan tarqatishni hisobga olganda, ish manbasini xavfsiz saqlab turish rolini ham o'ynaydi.
  • Tarqatish nomzod branchi ishga tushirishga mo'ljallangan funktsiyalarni to'plab, oxirgi tasdiqlash uchun mo'ljallangan vaqtincha branchdir.

Asosiy nuqta, ishga tushirishdan oldin alohida tarqatish nomzod branchini yaratish va shu tarqatish uchun mo'ljallangan funktsiyalarni to'plaganimizdir. Rivojlanish branchiga kiritilgan barcha funktsiyalar ushbu ishga tushirish tarqatishiga kiritilmadi, shuning uchun ishga tushirish branchi asosida tarqatish nomzod branchini yaratib, tarqatish doirasini aniq nazorat qildik.

Bu tuzilma an'anaviy Git Flow deb tasniflash qiyin. GitLab Flow kabi muhit branchlaridan foydalanish jihatlari ham bor, Git Flow release branchi kabi ishga tushirish oldi barqarorlik branchiga ega bo'lish jihatlari ham bor. Biroq, developdan release branchini olish an'anaviy Git Flowga qaraganda, ishga tushirish branchini asoslab, tanlangan funktsiyalarni to'plaganligimiz bilan amaliy hybrid tuzilishga yaqin.

4.1 Umumiy rivojlanish jarayoni

Har bir rivojlantiruvchi ishga tushirish branchidan yoki jamoa belgilagan eng yangi mezon branchidan feature branchini yaratadi va rivojlantirish tugagach, rivojlanish branchiga birlashtirgan va rivojlanish muhitida sinovdan o'tkazgan. Bu yerda mezon branch jamoa siyosatiga qarab o'zgarishi mumkin. Muhimi, qaysi branchdan boshlanadi va qaysi branchga birinchi bo'lib birlashtiriladi, jamoaning to'liq tarkibi bir xil bilishi kerak.

feature/A -> 개발 브랜치 -> 개발계 배포 및 테스트
feature/B -> 개발 브랜치 -> 개발계 배포 및 테스트
feature/C -> 개발 브랜치 -> 개발계 배포 및 테스트

Bu yerda muhim narsa rivojlanish branchi ishga tushirish tarqatishining mezoni emasligidir. Rivojlanish branchiga kirgan barcha funktsiyalar ushbu ishga tushirish tarqatishiga kiritilmadi.

개발 브랜치 = 운영 코드 + feature/A + feature/B + feature/C
이번 배포 대상 = feature/A + feature/B

Yuqoridagi kabi holatlarda rivojlanish branchini to'g'ridan-to'g'ri ishga tushirishga birlashtirsak, feature/C ham birga chiqadi. Shuning uchun feature branchi oddiy ish maydoni emas, balki tarqatish doirasini tanlash mumkin bo'lgan birlik sifatida boshqarilishi kerak. Rivojlanish branchiga birlashtirilganidan so'ng, feature branchining asl manbasini to'g'ridan-to'g'ri o'chirish yoki ish tarixini yo'qotish, tanlangan tarqatish vaqtida yana jamlashni qiyinlashtiradi.

4.2 Tarqatish nomzod shaxobchasini yaratish

Tarqatish sanasi yaqinlashganda, ishga tushirish shaxobchasiga asoslanib tarqatish nomzod shaxobchasini yaratdim va ushbu tarqatishga kiritiladigan xususiyatlarni birma-bir birlashtirdim. Jamoalarga qarab, birlashishni ishlatish mumkin yoki zarur xabarlarni tanlash mumkin. Qanday usuldan foydalanilsa, asosiy narsa ishga tushirishni talab qiladigan o'zgarishlar faqat tarqatish nomzod shaxobchasida bo'lishi kerak.

개발 중: feature/A, feature/B, feature/C -> 개발 브랜치 -> 개발계 테스트
배포 준비: 운영 브랜치 -> 배포 후보 브랜치 <- feature/A, feature/B
최종 흐름: 충돌 해결 -> 의존성 확인 -> 검증 환경 테스트 -> 운영 PR -> 운영 배포

Ushbu tuzilmaning asosiy afzalliklaridan biri tarqatish doirasini aniq nazorat qilish imkoniyatidir. Rivojlanish shaxobchasida qandaydir funksiyalar aralashgan bo'lsa ham, ishga tushirishga ketadigan funksiyalarni tarqatish nomzod shaxobchasida to'plashi mumkin.

Ammo xususiyatlar o'rtasida bog'liqlik mavjud bo'lsa, ehtiyot bo'lish kerak. Masalan, xususiyat/B ichki ravishda xususiyat/C kodiga bog'liq bo'lsa, faqat B-ni tarqatish nomzodiga kiritish va C-ni chiqarib tashlash mumkin emas yoki bu xavfli bo'lishi mumkin. Tanlangan tarqatish talab qilingan tuzilma uchun xususiyatlarni mustaqil ravishda ajratish, bog'liqlikni tekshirish, xususiyat flag strategiyasi birga bo'lishi kerak.

4.3 Integratsiya, tasdiqlash, ishga tushirishga qo'shish

Tarqatish nomzod shaxobchasida eng ko'p e'tibor berishim kerak bo'lgan jihatlarni konflikt va oxirgi tasdiqlash edi. Xususiyat shaxobchasi ish joyini ajratadi, ammo integratsiya xarajatlarini yo'q qilmaydi. Bir nechta xususiyat bir vaqtning o'zida kompozit komponentlar, marshrut fayllari, turli aniqlashlar, sozlash fayllarini o'zgartirsa, tarqatish nomzod shaxobchasiga to'plangan paytda konfliktlar yuzaga kelishi mumkin.

Shuningdek, rivojlanish shaxobchasida test qilingan kombinatsiya va tarqatish nomzod shaxobchasidagi kombinatsiya boshqacha bo'lishi mumkin. Masalan, rivojlanish shaxobchasida A+B+C kombinatsiyasi bilan test qilingan bo'lsa, ishga tushirish nomzodiga faqat A+B kiritilishi mumkin. Shuning uchun oxirgi tasdiqlash rivojlanish shaxobchasida emas, balki asl ishga tushirishga ketadigan tarqatish nomzod shaxobchasi asosida amalga oshirilishi kerak.

Tasdiqlash tugagach, tarqatish nomzod shaxobchasini ishga tushirish shaxobchasiga birlashtirish uchun Pull Request yaratdim. Ushbu PR oddiy birlashtirish jarayoni emas, balki ushbu tarqatishga nimalar kiritiladiganligini tasdiqlashda asosiy nuqtani o'ynaydi. Kiritilgan xususiyatlar, chiqarib tashlangan xususiyatlar, konfliktlarni hal qilish, tasdiqlash natijalari, tarqatish sozlamalari o'zgarishlari, qaytish mezonlari bir joyga to'plangan bo'lsa, tarqatish barqarorligi yuqori bo'ladi.

Qisqacha aytganda, tarqatish nomzod shaxobchasi “tarqatiladigan xususiyatlarni yig'ishga mo'ljallangan vaqtincha shaxoba” bo'lib, bir vaqtning o'zida “ishga tushirishdan oldin oxirgi tasdiqlash mezonidir”. Shuning uchun tarqatishdan oldin tezda yaratish o'rniga yetarli tasdiqlash vaqtini ajratib berish xavfsizroqdir.

4.4 Tarqatishdan so'ng sinxronizatsiya va hotfix

Ishga tushirish tarqatilishi tugagandan so'ng, ishga tushirish shaxobchasi asosida rivojlanish shaxobchasi va tasdiqlash shaxobchalarini qayta moslashtirish jarayoni bo'lgan. Shunda tarqatishdan keyin asosiy nuqta aniq bo'ladi va shaxobchalar o'rtasi farqning davom etish muammosini kamaytiradi. Ushbu paytda ishga tushirish shaxobchasidagi o'zgarishlarni rivojlanish shaxobchasiga va tasdiqlash shaxobchasiga qaytarish orqali birlashtirish mumkin yoki jamoa siyosatiga qarab ayrim muhit shaxobchalarini ishga tushirish mezoni sifatida qayta moslashtirish mumkin.

Ammo umumiy shaxobchani force push yoki reset orqali yo'q qilish usuli xavfli ekanligi uchun istisno tariqasida foydalanish kerak. Ulanish shaxobchasini moslashtirish bilan tugamaydi, balki jamoa a'zolarining mahalliy shaxobchalarini ham yana sinxronizatsiya qilish kerak. Buyruqlarning o'zidan ko'ra, jamoa siyosati va bildirishnomalar muhimdir. Mezonlar aniq bo'lmasa, tarqatishdan so'ng sinxronizatsiya jarayonida yo'q qilingan kod yana qaytishi yoki, aksincha, zarur bo'lgan ishlar yo'qolishi mumkin.

Hotfix yetakchiligini ham alohida belgilab olish kerak. Ishga tushirish nosozligi yoki shoshilinch tuzatish oddiy xususiyatlardan ajratib tashlanishi kerak va odatda ishga tushirish shaxobchasida hotfix shaxobchasini yaratishadi, tuzatish va tasdiqlash tugagach, birinchi navbatda ishga tushirish shaxobchasiga aks etishi kerak. Keyin bir xil tuzatishning keyingi rivojlanish jarayonida yo'qolmasligi uchun rivojlanish shaxobchasiga, tasdiqlash shaxobchasiga va davom etayotgan tarqatish nomzod shaxobchasiga qaytarilishi kerak. Hotfixda refaktoring yoki alohida funksiya o'zgarishlarini aralashtirmaslik va doiralarni minimallashtirish xavfsizroqdir.

4.5 Ushbu tuzilmani qanday strategiya orqali ko'rish mumkin

Men boshidan kechirgan tuzilma to'g'ri Git Flow, GitHub Flow, GitLab Flow yoki Trunk-Based Development qatoridan birini aniq aytish qiyin. Rivojlanish shaxobchasi va ishga tushirish shaxobchasi o'rtasidagi farq Git Flow'ga o'xshaydi va tasdiqlash shaxobchasi va ishga tushirish shaxobchasi kabi muhit shaxobchalarni ifoda qilish GitLab Flow'ga o'xshaydi. Tarqatish nomzod shaxobchasini yaratish orqali ishga tushirishdan oldin barqarorlashtirish va tasdiqlash stsenariysi ham release shaxobcha strategiyasiga o'xshashdir.

Ammo, but bu tuzilma atrof-muhit tarmog'i va tarqatish nomzod tarmog'ini birlashtirib tanlov tarqatish gibrid strategiyasi sifatida tushunilishi eng to‘g‘ri edi.

5. Afzallik va ehtiyot choralar

5.1 Afzalliklar

  • Tarqatish doirasini aniq boshqarish mumkin. Dasturlash tarmog'ida bir necha funksiya aralashgan bo'lsa ham, tarqatish nomzod tarmog'ida faqat ushbu tarqatish ob'ekti to'planishi mumkin.
  • Dasturlash testlari va operatsion tarqatishni ajratish mumkin. Funksional tarmoqni dasturlash tarmog'iga birlashtirib, dasturlashda birinchi testni o'tkazish va operatsion davrda tarqatish nomzod tarmog'ida haqiqiy tarqatish tarkibini alohida tekshirish kerak.
  • Operatsion tarqatish birligi aniq bo'ladi. Tarqatish nomzod tarmog'i bitta bo'lganligi sababli, ushbu tarqatish doirasiga qaysi funksiyalarning kiritilishini aniqlash oson.
  • Operatsion tarmoqni barqaror asosiy nuqtada saqlash mumkin. Operatsion tarmoqda tarqatish nomzod tarmog'ini yaratish orqali, dasturlash tarmog'ida aralashgan tarqatilmagan funksiyalarning tasodifiy ravishda operatsiyaga qo'shilish xavfini kamaytiradi.
  • Tarqatishdan keyin asosiy nuqtalar tozalash qilinadi. Operatsion tarmoq asosida dasturlash/tekshirish tarmog'ini moslashtirish orqali, keyingi ishlarni joriy operatsion koddan qayta boshlash qiyin emas.

5.2 Ehtiyot choralar

  • Integratsiya xarajatlari tarqatishdan oldin to'planishi mumkin. Bir necha funksiyadan umumiy fayllarni o'zgartirish tarqatish nomzod tarmog'ini yaratish vaqtida konfliktlar to'planadi.
  • Dasturlash tarmog'i test kombinatsiyasi va operatsion nomzod kombinatsiyasi farqlanishi mumkin. Oxirgi tekshirish tarqatish nomzod tarmog'iga asoslangan bo'lishi kerak.
  • Funksiyalar o'rtasida yashirin bog'lanishlar bo'lsa, tanlov tarqatilishi buzilishi mumkin. A faqat tarqatilishini o'yladingiz, lekin aslida B yoki C kodiga bog'liq bo'lishi mumkin.
  • Merge va cherry-pick kabi yondashuvlar aralashsa, tarixni kuzatish qiyinlashishi mumkin. Jamoada qanday usuldan foydalanish aniq belgilang.
  • Taqsimlangan branchni yangilashdan keyin mahalliy sinxronizatsiyani o'tkazib yuborsangiz, olib tashlangan kod yana paydo bo'lishi mumkin. Taqsimlangan tarmoq olib borish oldindan ma'lum qilish va jamoa darajasida tartib qoidalarini talab qiladi.
  • Tugallanmalar ishlar funksional tarmoqda xavfsiz holda qolishi kerak. Dasturlash tarmog'ida ish aslini faqat dasturlash tarmog'iga qoldirsangiz, xavfli bo'lishi mumkin.
  • Yashirish kerak bo'lgan funktsiyalarni faqat branch orqali boshqarish yaxshiroqdir. Uzoq muddatli ko'rinmas funktsiyalar uchun feature flag yoki huquq boshqaruvini birgalikda ko'rib chiqish lozim.

5.3 Jamoa qoidalari qoldirilishi kerak bo'lgan narsalar

Branch strategiyasi rasm yoki nomdan ko'ra operatsion qoidalar sifatida qolganida xato qilish imkoniyati kamayadi. Mening tajribamga ko'ra, barcha narsalarni uzun ravishda hujjatlashtirish o'rniga, haqiqatan ham chalkash bo'lishi oson bo'lgan mezonlarni qisqa va aniq belgilab qo'ygan yaxshi.

  • Har bir branchning roli va himoya qilish holati
  • feature branchni yaratish uchun asosiy branch va birinchi bo'lib birlashadigan maqsad branch
  • Ishlab chiqish, tasdiqlash va ishga tushirish uchun tarqatish mezonlari
  • Tarqatish nomzod branchni yaratish vaqti va birlashtiriladigan featuresni belgilash usuli
  • Ishlatish branchi PR tasdiqlash shartlari va tarqatish ro'yxati
  • Ishlatish tarqatgandan so'ng ishlab chiqish/tasdiqlash branchlarining sinxronizatsiya usuli
  • hotfix boshlanish branchi, birlashtirilishi kerak bo'lgan branch, keyingi sinxronizatsiya jarayoni
  • feature flag ishlatish mezonlari va tarqatilmagan funktsiyalarni boshqarish usuli

6. Yakun

Git branch strategiyasida yagona javob yo'q. Git Flow, GitHub Flow, GitLab Flow, Trunk-Based Development har biri o'zining afzalliklari bo'lgan yaxshi mezonlardir, lekin haqiqiy loyihalarda tarqatish davri, QA usuli, operatsion xavf, CI/CD darajasi, jamoa o'lchamiga qarab o'zgaradi.

Mening tajribamga ko'ra, ushbu tuzilmani aniq Git Flow deb da'vo qilish mumkin emas edi. feature, ishlab chiqish, tasdiqlash, ishga tushirish, tarqatish nomzod branchlari birgalikda ishlatilgan va ishga tushirishdan keyin muhit branchini operatsion mezonlarga qayta moslashtirish siyosati ham mavjud edi. Bu nazariy strategiya emas, balki haqiqiy tarqatish barqarorligi va hamkorlik samaradorligi uchun yaratilgan amaliy tuzilishga yaqin edi.

Ushbu tajribadan eng esda qolarli ikkita narsani qayd etdim. Biri feature branchlar integratsiya xarajatlarini yo'q qilmasligi. Har kim branchlarda ishlasa-da, tarqatishdan oldin bitta branchda to'planishi kerak va o'sha paytda conflict yuzaga kelishi mumkin. "Qayerda ishlash kerak" qanchalik muhim bo'lsa, "qachon integratsiya qilish kerak" va "qayerda yakuniy tasdiqlash kerak" ham shunchalik muhimdir.

Boshqa biri esa brend strategiyasining mohiyati nomida emas, balki qoidalar aniqligida ekanligini ko'rsatadi. Har bir brendning roli, merge yo'nalishi, tarqatish mezonlari, tarqatilgandan keyingi sinxronizatsiya tartibi jamoa a'zolari tomonidan bir xil tarzda baham ko'rilishi kerak. Yaxshi brend strategiyasi mashhur strategiyani aynan takrorlash emas, balki bizning jamoamiz holatiga mos ravishda izchil amalga oshiriladigan strategiyadir.

Shu madda

- Git Flow: Vincent Driessen, nvie.com

- GitHub Flow: GitHub Docs

- GitLab Flow: GitLab rasmiy sayti, GitLab Docs

- Trunk-Based Development: TrunkBasedDevelopment.com

- Trunk-Based Development: Atlassian

yashil

Site footer