Mobil ishlab chiqishda Git va versiyalarni boshqarish: bu nima, asosiy buyruqlar va qanday ishlaydi

Versiyalarni boshqarish va Git: bu nima?

Git bu 2005 yilda Linus Torvalds tomonidan Linux yadrosini ishlab chiqish uchun yaratilgan taqsimlangan versiyalarni boshqarish tizimi (VCS). Markazlashtirilgan tizimlardan (SVN, CVS) farqli o'laroq, Git har bir dasturchining kompyuterida loyiha tarixining to'liq nusxasini saqlaydi. Bu shuni anglatadiki, siz internetga ulanmagan holda ham commit qilishingiz, tarixni ko'rib chiqishingiz va shoxlar yaratishingiz mumkin.

Git snapshot lar bilan ishlaydi — har bir commit saqlash vaqtidagi barcha loyiha fayllarining holatini saqlaydi. Agar fayl o'zgarmagan bo'lsa, Git oldingi versiyaga havola yaratadi, joyni tejaydi. GitHub tahliliga (2025) ko'ra, o'rtacha depoda 1.200 commit va 15 ta shox mavjud.

IT Sectr da biz 2017 yildan beri barcha loyihalarda Git dan foydalanamiz. Tajribamiz shuni ko'rsatadiki, birinchi kundan boshlab to'g'ri Git konfiguratsiyasi jamoaga birlashtirish va nizolarni hal qilishda 30% gacha vaqt tejaydi. Git de-fakto standartga aylandi — uni barcha zamonaviy IDE lar (Android Studio, Xcode, VS Code) va CI/CD tizimlari qo'llab-quvvatlaydi.

# Git asosiy sozlamalari
git config --global user.name "Sizning Ismingiz"
git config --global user.email "sizning@emailingiz.com"

# Yangi depo yaratish
git init my-project
cd my-project

# Fayllarni qo'shish va commit
git add README.md
git commit -m "Initial commit"

# Masofaviy depo bilan ishlash
git remote add origin https://github.com/user/my-project.git
git push -u origin main

Yuqoridagi kod asosiy ketma-ketlikni ko'rsatadi: deponi boshlash, birinchi commit va masofaviy serverda nashr qilish. git init buyrug'i butun loyiha tarixini saqlaydigan yashirin .git papkasini yaratadi. Har bir git commit istalgan vaqtda qaytishingiz mumkin bo'lgan tiklash nuqtasini yaratadi.

Asosiy tushunchalar: Repository, Branch, Commit

Uchta asosiy tushunchani — Repository, Branch va Commit — tushunish har qanday versiyalarni boshqarish tizimi bilan ishlash uchun zarurdir. Depo butun loyiha uchun konteynerdir. Commit fayllarning saqlangan holatidir. Branch rivojlanishning alohida chizig'idir.

Repository (depo) mahalliy (kompyuteringizda) yoki masofaviy (GitHub, GitLab serverida) bo'lishi mumkin. Har bir dasturchi masofaviy deponi o'z mashinasiga klonlaydi va mahalliy nusxa bilan ishlaydi. O'zgarishlar push (yuborish) va pull (olish) orqali sinxronlashtiriladi. Taqsimlangan versiyalarni boshqarishda, har bir dasturchi tarixning to'liq nusxasini saqlaydi.

Branch (shox) commitlardan biriga ishora qiluvchi ko'rsatkichdir. Shoxlar parallel rivojlanishga imkon beradi: bir dasturchi yangi funksiya (feature branch) ustida, ikkinchisi xatoni tuzatish (hotfix branch), uchinchisi nashrni tayyorlash (release branch) ustida ishlaydi. GitLab Flow (2025) ma'lumotlariga ko'ra, o'rtacha loyihada bir vaqtning o'zida 3–5 faol shox mavjud.

Commit o'zgarish birligidir. Har bir commit noyob hash (SHA-1), xabar, muallif va vaqt tamg'asini o'z ichiga oladi. Yaxshi amaliyot tavsiflovchi xabarlar bilan kichik mazmunli commitlar qilishdir — bu Kod Tekshiruvi va o'zgarishlarni qaytarishni soddalashtiradi. Commitlar orqali versiyalarni boshqarish sizga loyihaning to'liq tarixini beradi.

Feature Branch

Feature Branch (funksiya shoxi) muayyan vazifani ishlab chiqish uchun develop yoki main dan yaratilgan vaqtinchalik shoxdir. Ish tugagach, shox Pull Request orqali qayta birlashtiriladi va o'chiriladi. Bu amaliyot asosiy kod bazasining barqarorligini buzmasdan o'zgarishlarni ajratishga imkon beradi.

Oddiy ish oqimi: feature/add-login shoxini yaratish → bir necha commit qilish → Pull Request yaratish → Kod Tekshiruvidan o'tish → develop ga birlashtirish. IT Sectr da biz aynan shu yondashuvdan foydalanamiz: har bir Jira vazifasi alohida feature shoxiga mos keladi. Bu o'zgarishlarni kuzatish va kerak bo'lganda qaytarishni soddalashtiradi.

Rebase vs Merge

Merge ikkita shoxni birlashtiruvchi birlashma commitini yaratadi. U parallel rivojlanish chiziqlarini ham o'z ichiga olgan to'liq tarixni saqlaydi. Rebase tarixni qayta yozadi: bir shoxdan commitlarni oladi va ularni boshqa shox ustiga "qayta qo'llaydi", chiziqli tarix yaratadi.

Merge xronologiya muhim bo'lgan ommaviy shoxlar va katta jamoalar uchun ko'proq mos keladi. Rebase PR yaratishdan oldin shaxsiy feature shoxlari uchun qulay — tarixni toza va tushunarli qiladi. Biroq, rebase tarixni qayta yozgani uchun boshqa dasturchilar ishlayotgan shoxlarga hech qachon qo'llanilmasligi kerak.

# Feature shoxini yaratish va unga o'tish
git checkout -b feature/add-login main

# Shoxda ishlash
git add login-screen/
git commit -m "Add login screen layout"

# PR dan oldin eng so'nggi main ga Rebase
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Masofaviy depoga Push
git push origin feature/add-login

Bu misol odatdagi ish oqimini ko'rsatadi: main dan feature shoxini yaratish, bir nechta commit va ko'rib chiqishga yuborishdan oldin toza chiziqli tarix olish uchun rebase. Bu yondashuv birlashma nizolarini kamaytiradi.

Git Flow vs Trunk-Based Development

Git Flow va Trunk-Based Development jamoa Git bilan ishni qanday tashkil qilishini belgilaydigan ikkita asosiy versiyalarni boshqarish strategiyasidir. Tanlov jamoa hajmiga, nashr chastotasiga va barqarorlik talablariga bog'liq.

Git Flow bir nechta doimiy shoxlari bo'lgan qat'iy modeldir: main (nashr kodi), develop (joriy rivojlanish), feature/* (yangi funksiyalar), release/* (nashr tayyorlash) va hotfix/* (shoshilinch tuzatishlar). Bu model aniq nashr sikllari bo'lgan loyihalar uchun yaxshi (masalan, 1.0, 2.0 versiyalari bo'lgan mobil ilovalar).

Trunk-Based Development barcha dasturchilar kuniga bir necha marta o'zgarishlarni birlashtiradigan yagona asosiy shox (trunk/main) yondashuvidir. Tugallanmagan funksiyalarni yashirish uchun funksiya bayroqlari ishlatiladi. Bu yondashuv yetkazib berish tezligi muhim bo'lgan veb-ishlab chiqish va startaplarda mashhur.

Git Flow

Git Flow, 2010 yilda Vincent Driessen tomonidan taklif qilingan, eng mashhur modellardan biri bo'lib qolmoqda. Uning asosiy afzalligi kodni hayotiy tsikl bosqichlari bo'yicha qat'iy ajratishdir. main shoxi faqat nashr kodini o'z ichiga oladi, develop joriy rivojlanishni o'z ichiga oladi va feature shoxlari yangi funksiyalarni bir-biridan ajratadi.

Hotfix shoxlari shoshilinch tuzatishlar uchun main dan yaratiladi va birlashtirilgandan so'ng main va develop ga qayta birlashtiriladi. Release shoxlari jamoa nashrga tayyor bo'lganda develop dan yaratiladi. Ularga faqat xato tuzatishlari va meta ma'lumotlar (versiya, build) qo'shiladi. Nashrdan so'ng, release shoxi main va develop ga birlashtiriladi. JetBrains so'roviga (2024) ko'ra, jamoalarning 37% i Git Flow dan foydalanadi. Ushbu versiyalarni boshqarish modeli belgilangan nashrlari bo'lgan loyihalar uchun standart bo'lib qolmoqda.

# Git Flow misoli: nashr ustida ishni boshlash
git checkout -b release/1.2.0 develop

# release shoxida xatolarni tuzatish
git commit -m "Fix login button crash"

# Nashrni yakunlash — main va develop ga birlashtirish
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# release shoxini o'chirish
git branch -d release/1.2.0

Kod release shoxini yaratish, uni barqarorlashtirish va asosiy shoxlarga birlashtirishni ko'rsatadi. --no-ff bayrog'i birlashma commitini kafolatlaydi, o'zgarishlar release shoxidan kelganligi haqidagi ma'lumotni saqlaydi.

Pull Request va Kod Tekshiruvi

Pull Request (PR) dasturchining o'z shoxidan asosiy shoxga o'zgarishlarni taklif qiladigan mexanizmidir. PR jamoa ishida versiyalarni boshqarishning asosiy elementidir — bu shunchaki kodni birlashtirish usuli emas, balki muhokama, tekshirish va sifat nazorati jarayonidir. GitLab da shunga o'xshash mexanizm Merge Request (MR) deb ataladi, ammo mohiyati bir xil: jamoani o'zgarishlar haqida xabardor qilish va tasdiqlash olish.

Yaxshi PR kichik (300 satr kodgacha), bitta vazifaga qaratilgan va nima qilingani va nima uchun qilinganining tavsifini o'z ichiga olishi kerak. Google tadqiqotiga (2025) ko'ra, 400 satrdan ortiq PR larni tekshirish ikki baravar ko'p vaqt oladi va xatolarni aniqlash ehtimoli 30% ga kamayadi. Kod Tekshiruvi (Code Review) birlashtirishdan oldin kodni boshqa dasturchi tomonidan tekshirishdir.

IT Sectr da biz har bir PR uchun majburiy Kod Tekshiruvini qo'llaymiz. Bu nafaqat kod sifatini yaxshilaydi, balki jamoa ichida bilim tarqatishga ham yordam beradi. Kod Tekshiruvi quyidagilarni tekshiradi: kod arxitektura tamoyillariga mos keladimi, xatolar bormi, testlar yetarlimi, o'zgaruvchilar to'g'ri nomlangammi. Barcha mulohazalar birlashtirilgunga qadar PR da muhokama qilinadi.

Platformalar: GitHub, GitLab, Bitbucket

Git protokol, ammo hamkorlik uchun veb interfeys, kirish boshqaruvi, CI/CD va tekshirish vositalarini ta'minlaydigan versiyalarni boshqarish platformasi kerak. Bozorda uchta platforma hukmron: GitHub, GitLab va Bitbucket.

GitHub 56 milliondan ortiq dasturchiga ega eng yirik platformadir. Microsoft ga tegishli, Actions (CI/CD), Pages (hosting), Discussions va Copilot ni taklif etadi. Bepul tarif 3 kishigacha bo'lgan jamoalar uchun cheksiz xususiy depolarni o'z ichiga oladi. GitHub ochiq kod hamjamiyatida mashhur.

GitLab integratsiyalashgan CI/CD, konteyner reestri va infratuzilma boshqaruvi bilan to'liq DevOps platformasidir. GitHub dan farqli o'laroq, GitLab o'z serveringizda o'rnatilishi mumkin (Self-Managed). Atlassian ning Bitbucket i Jira va Confluence bilan chambarchas integratsiyalashgan bo'lib, uni allaqachon Atlassian ekotizimidan foydalanadigan jamoalar uchun tanlovga aylantiradi.