Main va Master Branch Gitda: bu nima va asosiy filial nima uchun kerak

Gitda Main / Master Branch nima

Main Branch (yoki Master — repozitoriy sozlamalariga qarab) — har qanday Git repozitoriyini ishga tushirishda yaratiladigan standart filialdir. Bu loyihaning asosiy filiali bo'lib, ishlab chiqarishga joylashtirishga tayyor kodni o'z ichiga oladi.

Kundalik ish yangi funksiyalar bilan qaynaydigan developdan farqli o'laroq, main loyihaning oynasidir. Maindagi kodning har bir versiyasi to'liq sikldan o'tgan: feature filialida ishlab chiqish, developda integratsiya, release filialida relizga tayyorgarlik va yakuniy testlash. Shundan keyingina o'zgarishlar mainga kiradi.

Asosiy prinsip: main har doim barqaror bo'lishi kerak. Agar mainda xato topsa, bu navbatdan tashqari hotfixni talab qiladi. Shuning uchun professional loyihalarda main branch protection rules bilan tasodifiy o'zgarishlardan himoyalangan.

Git Bookga ko'ra, main maxsus xususiyatlarga ega filial emas, balki konvensiyaga ko'ra asosiy hisoblanadigan oddiy commit havolasidir. Git tizim darajasida main va boshqa har qanday filial o'rtasida farq qilmaydi.

Masterdan mainga o'tish

Tarixiy jihatdan, Gitdagi standart filial master deb nomlangan. 2020 yil iyun oyida Black Lives Matter harakati IT sanoatida master va slave atamalariga e'tibor qaratdi. GitHub standart filial uchun main atamasiga o'tishni e'lon qildi.

2020 yil oktyabridan boshlab GitHubdagi barcha yangi repozitoriyalar main filiali bilan yaratiladi. GitLab va Bitbucket ham mainni standart nom sifatida qo'llab-quvvatlashni joriy qildi. Git 2.28 (iyul 2020) standart filial nomini sozlash uchun init.defaultBranch variantini qo'shdi.

Texnik jihatdan, mavjud filialni masterdan mainga qayta nomlash oddiy operatsiyadir. Asosiy qiyinchilik — CI/CD konfiguratsiyalari, hujjatlar va dasturchilarning mahalliy repozitoriyalaridagi barcha havolalarni yangilash.

Mavjud repozitoriyada filial nomini o'zgartirish uchun bajaring:

# Masterni mahalliy mainga qayta nomlash
git branch -m master main

# Uzoqdagi repozitoriyani yangilash
git push -u origin main

# Serverdagi eski masterni o'chirish
git push origin --delete master

# Serverda HEADni yangilash
# (GitHub veb interfeysi orqali: Settings → Branches → Default branch)

Mainning Git Flow va GitHub Flowdagi roli

Git Flow va GitHub Flow main filialining rolini turlicha belgilaydi. Modelni tanlash jamoa hajmi, reliz chastotasi va kod barqarorligi talablariga bog'liq.

Mobil ilova ishlab chiqish uchun standart Git Flow hisoblanadi, chunki App Store va Google Play'da ilovalarni nashr qilish qat'iy reliz sikllariga ega. GitHub Flow kuniga bir necha marta joylashtirish imkoniyatiga ega veb loyihalar uchun ko'proq mos keladi.

GitHub Flow — soddalashtirilgan yondashuv

GitHub Flowda develop filiali mavjud emas. Barcha feature filiallari to'g'ridan-to'g'ri maindan yaratiladi va tugatilgandan so'ng Pull Request orqali qayta birlashtiriladi. Mainga har bir birlashish avtomatik ravishda ishlab chiqarishga joylashtirishni ishga tushiradi. Bu model yuqori test avtomatlashtirish va jamoa intizomini talab qiladi.

GitHub Flowda develop filiali mavjud emas. Barcha feature filiallari to'g'ridan-to'g'ri maindan yaratiladi va tugatilgandan so'ng Pull Request orqali qayta birlashtiriladi. Mainga har bir birlashish avtomatik ravishda ishlab chiqarishga joylashtirishni ishga tushiradi. Bu model yuqori test avtomatlashtirish va jamoa intizomini talab qiladi.

Main filialini himoya qilish

Branch protection main uchun — har qanday tijorat loyihasida majburiy sozlamadir. Busiz tasodifiy push tugallanmagan kodni ishlab chiqarishga yuborishi yoki barcha foydalanuvchilar uchun ishlayotgan ilovani buzishi mumkin.

• Require pull request — mainga to'g'ridan-to'g'ri push taqiqlangan. Barcha o'zgarishlar PR orqali, ko'rib chiqish bilan.
• Require approvals — mainga birlashish uchun kamida 2 ta ma'qullash (bir ko'rib chiquvchining xatosi bo'lsa).
• Require status checks — birlashishdan oldin barcha CI/CD tekshiruvlari muvaffaqiyatli bo'lishi kerak.
• Require up-to-date — PR mainning eng so'nggi commitiga asoslangan bo'lishi kerak.
• Include administrators — himoya hatto repozitoriy egalariga ham qo'llaniladi.
• Require signed commits — maindagi barcha commitlar GPG kalit bilan imzolanishi kerak.

Barcha olti qoidani sozlash — 10 000+ foydalanuvchiga ega mobil loyihalar uchun standartdir. Kichik loyihalar uchun birinchi uchta qoida yetarli.

Turli loyiha turlari uchun himoya darajalarini taqqoslash

Main himoyasi darajasi loyiha miqyosiga bog'liq. Startap minimal himoya bilan ishlashi mumkin, enterprise ilova esa maksimal cheklovlarni talab qiladi.

Mainda relizlar va teglar

Teglash (tagging) — maindagi aniq commitlarga nomlangan havolalar yaratish amaliyotidir. Har bir teg ishlab chiqarishga chiqarilgan ilova versiyasiga mos keladi. Bu disk raskadrovka yoki patch uchun istalgan oldingi relizga tez o'tish imkonini beradi.

Mobil ilova ishlab chiqishda teg nomlash standarti — SemVer (Semantic Versioning): v1.2.3, bu yerda birinchi raqam — asosiy versiya (breaking changes), ikkinchi — kichik (yangi funksiyalar), uchinchi — patch (tuzatishlar).

Teg release filialining mainga birlashishidan so'ng yaratiladi. Bu commit keyin CI/CDda quriladi, imzolanadi va ilova do'koniga yuboriladi. Agar tegda xato topilsa, shu tegdan hotfix filiali yaratiladi.

# Annotatsiyalangan reliz tegini yaratish
git tag -a v2.4.1 -m "Release version 2.4.1"

# Tegni serverga jo'natish
git push origin v2.4.1

# Repozitoriyadagi barcha teglarni ko'rish
git tag -l "v2.*"

# Muayyan tegdan hotfix filialini yaratish
git checkout -b hotfix/crash-fix v2.4.1

Git Flow filial iyerarxiyasi

Git Flowda filial iyerarxiyasini tushunish — birgalikdagi ishlanmani to'g'ri tashkil qilish asosidir. Har bir filial turi o'z manbasiga, maqsadiga va birlashtirish qoidalariga ega.

• Main (1-daraja) — ildiz filial, faqat reliz versiyalarini o'z ichiga oladi. Repozitoriy ishga tushirilganda yaratiladi.
• Develop (2-daraja) — loyiha boshida maindan yaratiladi. Barcha funksiyalarning integratsiya kodini o'z ichiga oladi.
• Feature (3-daraja) — developdan yaratiladi. Alohida funksiyalarning izolyatsiyalangan ishlanmasi.
• Release (2-daraja) — developdan yaratiladi. Muayyan relizni chiqarishga tayyorlash.
• Hotfix (2-daraja) — maindan yaratiladi. Ishlab chiqarishdagi kritik xatolarni shoshilinch tuzatish.

Muhim qoida: feature hech qachon to'g'ridan-to'g'ri mainga birlashtirilmaydi. feature → develop → release → main — to'g'ri birlashish zanjiri. Bu qoidani buzish butun Git Flow modelini ma'nosiz qiladi.

Main bilan ishlash uchun buyruq misollari

Stsenariyni ko'rib chiqaylik: jamoa v2.5.0 relizini tayyorlashni tugatdi. Release filiali tekshirildi va mainga birlashishga tayyor. Birlashishdan so'ng teg yaratiladi va reliz nashr etiladi.

# Mainga o'tish va yangilash
git checkout main
git pull origin main

# Tekshirilgan release filialini birlashtirish
git merge --no-ff release/2.5.0

# Reliz tegini yaratish
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Main va tegni serverga jo'natish
git push origin main --tags

--no-ff (no fast-forward) bayrog'i, birlashish ko'rsatkichni oddiy siljitish orqali amalga oshirilishi mumkin bo'lsa ham, birlashish commitini yaratishni kafolatlaydi. Bu o'zgarishlar release filialidan kelganligi haqidagi ma'lumotni saqlaydi, bu esa tarix tahlilini osonlashtiradi.

Main orqali hotfix bilan ishlash

Ishlab chiqarishda kritik xato topilsa, jarayon oddiy relizdan farq qiladi. Hotfix maindan yaratiladi va tuzatilgandan so'ng ham mainga, ham developga birlashtiriladi.

Ishlab chiqarishda kritik xato topilsa, jarayon oddiy relizdan farq qiladi. Hotfix maindan yaratiladi va tuzatilgandan so'ng ham mainga, ham developga birlashtiriladi.

# Maindan hotfix filialini yaratish
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Tuzatish va commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Hotfixni mainga qaytarish
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Hotfixni developga ham birlashtirish
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Hotfix filialini o'chirish
git branch -d hotfix/2.5.1-crash-fix