Pull request

Pull request — Git platformalarida bir branchdagi o‘zgarishlarni boshqa branchga qo‘shishdan oldin ko‘rib chiqish, muhokama qilish va tasdiqlash jarayoni. Pull request ko‘pincha GitHub, GitLab, Bitbucket va Azure DevOps kabi platformalarda ishlatiladi.

Pull request orqali dasturchi yozgan kodini asosiy branchga bevosita qo‘shmaydi, avval o‘zgarishlarni jamoaga ko‘rsatadi. Keyin kod ko‘rib chiqiladi, testlardan o‘tadi va kerak bo‘lsa asosiy branchga merge qilinadi.

Vazifasi

Pull request kod o‘zgarishlarini nazorat bilan asosiy branchga qo‘shish uchun ishlatiladi.

Pull request quyidagi vazifalarni bajaradi:

• branchdagi o‘zgarishlarni ko‘rsatish;
• code review jarayonini tashkil qilish;
• o‘zgargan fayllarni solishtirish;
• commitlar tarixini ko‘rsatish;
• jamoa muhokamasini yuritish;
• test va CI/CD natijalarini tekshirish;
• conflict bor yoki yo‘qligini aniqlash;
• merge qilishdan oldin tasdiq olish;
• asosiy branchni bevosita xatolardan himoya qilish.

Masalan, feature/login branchida login funksiyasi yozilgan bo‘lsa, bu o‘zgarishlarni main branchga qo‘shish uchun pull request ochiladi.

Pull request qanday ishlaydi?

Pull request branchlar orasidagi o‘zgarishlarni ko‘rsatadi. Odatda bir branchda kod yoziladi, keyin shu branchdan asosiy branchga pull request ochiladi.

Oddiy jarayon:

• yangi branch yaratiladi;
• kod o‘zgarishlari commit qilinadi;
• branch remote repositoryga push qilinadi;
• GitHub yoki GitLab’da pull request ochiladi;
• reviewerlar kodni ko‘rib chiqadi;
• testlar va CI/CD tekshiruvlari bajariladi;
• kerak bo‘lsa o‘zgarishlar qayta ishlanadi;
• pull request tasdiqlanadi;
• branch asosiy branchga merge qilinadi.

Pull request jamoaviy ishlashda kodni bevosita emas, tekshiruvdan keyin birlashtirishga yordam beradi.

Source branch va target branch

Pull request ikki branch o‘rtasida ochiladi.

• Source branch — o‘zgarishlar yozilgan branch;
• Target branch — o‘zgarishlar qo‘shilishi kerak bo‘lgan branch.

Masalan:

• source branch: feature/payment;
• target branch: main.

Bu holatda feature/payment branchidagi commitlar main branchga qo‘shilishi uchun pull request ochiladi.

Pull request title

Pull request title — pull request mavzusini bildiradigan sarlavha. Title o‘zgarish nima haqida ekanini qisqa ko‘rsatadi.

Pull request title misollari:

• Add login page;
• Fix mobile navbar;
• Update payment validation;
• Add product search API;
• Refactor user service.

Title pull request ro‘yxatida ko‘rinadi va o‘zgarish mazmunini tez tushunishga yordam beradi.

Pull request description

Pull request description — pull request ichidagi o‘zgarishlar haqida batafsilroq ma’lumot beradigan qism.

Description ichida quyidagilar bo‘lishi mumkin:

• nima o‘zgargani;
• qaysi muammo hal qilingani;
• qaysi fayllar yoki modullar o‘zgargani;
• test holati;
• screenshot yoki video;
• bog‘liq issue havolasi;
• deployment yoki migration haqida ma’lumot.

Description reviewerga pull request mazmunini tushunishga yordam beradi.

Commitlar

Pull request ichida bir yoki bir nechta commit bo‘lishi mumkin. Har bir commit branchdagi alohida saqlangan o‘zgarish nuqtasini bildiradi.

Pull request commitlari orqali quyidagilar ko‘rinadi:

• o‘zgarishlar qaysi bosqichlarda qilingan;
• har bir commit nima vazifa bajargan;
• muallif kim bo‘lgan;
• commitlar qachon yaratilgan;
• branch tarixi qanday shakllangan.

Commitlar pull requestdagi o‘zgarishlar tarixini ko‘rsatadi.

Files changed

Files changed — pull requestda o‘zgargan fayllarni ko‘rsatadigan bo‘lim. Bu bo‘limda eski va yangi kod farqi ko‘rinadi.

Files changed orqali quyidagilarni ko‘rish mumkin:

• qaysi fayllar o‘zgargan;
• qaysi qatorlar qo‘shilgan;
• qaysi qatorlar o‘chirilgan;
• qaysi kod bloklari tahrirlangan;
• yangi fayllar;
• o‘chirilgan fayllar;
• konfiguratsiya o‘zgarishlari.

Code review jarayoni ko‘pincha shu bo‘lim orqali bajariladi.

Diff

Diff — eski va yangi kod o‘rtasidagi farq. Pull request diff orqali branchdagi o‘zgarishlarni aniq ko‘rsatadi.

Diff ichida:

• qo‘shilgan qatorlar belgilanadi;
• o‘chirilgan qatorlar belgilanadi;
• o‘zgargan fayllar ko‘rsatiladi;
• kod bloklari solishtiriladi;
• review izohlari qatorlarga yozilishi mumkin.

Diff pull requestning asosiy ko‘rib chiqiladigan qismidir.

Code review

Code review — pull requestdagi kodni boshqa dasturchilar tomonidan tekshirish jarayoni. Reviewerlar kod sifatini, mantiqini, xavfsizligini va loyiha standartlariga mosligini ko‘rib chiqadi.

Code review’da quyidagilar tekshirilishi mumkin:

• kod ishlash mantiqi;
• xatolik ehtimoli;
• naming;
• arxitektura;
• performance;
• xavfsizlik;
• testlar;
• dokumentatsiya;
• formatlash;
• dependency o‘zgarishlari.

Reviewerlar pull request ichida izoh qoldirishi, o‘zgarish so‘rashi yoki tasdiqlashi mumkin.

Reviewer

Reviewer — pull requestdagi kodni ko‘rib chiqadigan shaxs. Reviewer kodni tekshiradi va pull request holatini baholaydi.

Reviewer quyidagi amallarni bajarishi mumkin:

• kodga izoh yozish;
• qator bo‘yicha savol berish;
• o‘zgarish so‘rash;
• pull requestni tasdiqlash;
• test natijalarini ko‘rish;
• merge qilishga ruxsat berish.

Jamoaviy loyihalarda reviewerlar kod sifati va asosiy branch barqarorligini saqlashda muhim rol o‘ynaydi.

Approval

Approval — reviewer pull requestdagi o‘zgarishlarni tasdiqlaganini bildiradi. Approval berilgandan keyin pull request merge qilishga tayyor holatga kelishi mumkin.

Approval quyidagi holatlarni bildirishi mumkin:

• kod ko‘rib chiqilgan;
• o‘zgarishlar qabul qilingan;
• jiddiy muammo topilmagan;
• pull request merge qilishga tayyor;
• branch protection talabi bajarilgan.

GitHub va GitLab’da approval branch protection qoidalari bilan bog‘lanishi mumkin.

Request changes

Request changes — reviewer pull requestda o‘zgarish talab qilgan holat. Bu holatda pull request odatda merge qilinmaydi, avval kerakli tuzatishlar kiritiladi.

Request changes quyidagi sabablar bilan berilishi mumkin:

• kodda xatolik bor;
• test yetishmaydi;
• xavfsizlik muammosi mavjud;
• mantiq noto‘g‘ri ishlangan;
• loyiha standartiga mos emas;
• keraksiz kod bor;
• performance muammosi bor.

Dasturchi kerakli tuzatishlarni qo‘shimcha commit sifatida shu branchga push qiladi.

Comment

Pull request ichida umumiy yoki qator bo‘yicha comment yozish mumkin. Comment muhokama, savol, tushuntirish yoki tekshiruv natijasi sifatida ishlatiladi.

Comment turlari:

• umumiy pull request comment;
• kod qatoriga yozilgan comment;
• review comment;
• resolved comment;
• bot yoki CI comment;
• issue bilan bog‘langan comment.

Commentlar pull request atrofidagi texnik muhokamani saqlab boradi.

Conversation

Conversation — pull request ichidagi umumiy muhokama bo‘limi. Bu yerda dasturchilar o‘zgarishlar, savollar, natijalar va qarorlar haqida yozishadi.

Conversation bo‘limida quyidagilar bo‘lishi mumkin:

• pull request tavsifi;
• reviewer izohlari;
• commit yangilanishlari;
• test natijalari;
• bot xabarlari;
• linked issue ma’lumotlari;
• approval yoki request changes holatlari.

Conversation pull requestning muhokama tarixini saqlaydi.

Status checks

Status checks — pull requestdagi kod avtomatik tekshiruvlardan o‘tgan-o‘tmaganini ko‘rsatadigan holat.

Status checks quyidagilarni bildirishi mumkin:

• testlar muvaffaqiyatli o‘tdi;
• testlarda xatolik chiqdi;
• build yakunlandi;
• lint tekshiruvi o‘tdi;
• security scan bajarildi;
• deploy preview yaratildi;
• CI/CD pipeline tugadi.

Ayrim repositorylarda status checks o‘tmaguncha pull request merge qilinmaydi.

CI/CD bilan bog‘lanishi

Pull request ochilganda CI/CD pipeline avtomatik ishga tushishi mumkin. Bu kod asosiy branchga qo‘shilishidan oldin tekshiruvlardan o‘tishini ta’minlaydi.

Pull requestda CI/CD quyidagilarni bajarishi mumkin:

• dependency o‘rnatish;
• testlarni ishga tushirish;
• lint tekshirish;
• build qilish;
• type checking bajarish;
• Docker image yaratish;
• security scan;
• preview deploy.

Masalan, React loyihasida pull request ochilganda testlar va build jarayoni avtomatik bajarilishi mumkin.

Conflict

Conflict — pull requestdagi branch target branch bilan avtomatik birlasha olmagan holat. Conflict odatda ikki branch bir xil faylning bir xil joyini turlicha o‘zgartirganda yuz beradi.

Conflict quyidagi holatlarda chiqishi mumkin:

• bir xil qatorlar turlicha tahrirlanganda;
• fayl bir branchda o‘chirilgan, boshqasida o‘zgartirilgan bo‘lsa;
• target branchda yangi o‘zgarishlar ko‘payib ketganda;
• rebase yoki merge jarayonida mos kelmaydigan kod bo‘lsa.

Conflict hal qilingandan keyin pull request yana merge qilinishi mumkin.

Merge

Merge — pull requestdagi o‘zgarishlarni target branchga qo‘shish jarayoni. Merge pull request jarayonining yakuniy bosqichlaridan biri hisoblanadi.

Merge qilinganda:

• source branchdagi commitlar target branchga qo‘shiladi;
• pull request yopiladi;
• asosiy branch yangilanadi;
• CI/CD pipeline ishga tushishi mumkin;
• deployment jarayoni boshlanishi mumkin.

Masalan, feature/login branchidagi o‘zgarishlar main branchga merge qilinadi.

Merge commit

Merge commit — pull request merge qilinganda yaratiladigan maxsus commit turi. U ikki branch tarixining birlashganini bildiradi.

Merge commit orqali:

• feature branch tarixi saqlanadi;
• branchlar qayerda birlashgani ko‘rinadi;
• pull request tarixi Git logda ko‘rinadi;
• barcha commitlar alohida qoladi.

Merge commit katta jamoalarda branch tarixini aniq ko‘rsatishi mumkin.

Squash merge

Squash merge — pull requestdagi bir nechta commitni bitta commitga birlashtirib target branchga qo‘shish usuli.

Squash merge natijasida:

• target branchda bitta commit paydo bo‘ladi;
• pull requestdagi ichki commitlar ixchamlanadi;
• Git tarixi soddaroq ko‘rinadi;
• pull request bitta mantiqiy o‘zgarish sifatida saqlanadi.

Masalan, 8 ta kichik commitdan iborat pull request Add user profile page nomli bitta commit sifatida merge qilinishi mumkin.

Rebase merge

Rebase merge — pull request commitlarini target branchning oxirgi holati ustiga joylashtirib qo‘shish usuli.

Rebase merge natijasida:

• Git tarixi chiziqli ko‘rinishi mumkin;
• alohida merge commit yaratilmasligi mumkin;
• commitlar target branch davomiga qo‘shiladi;
• branch tarixi qayta tartiblanadi.

Rebase merge Git tarixini o‘zgartirish xususiyatiga ega bo‘lgan merge usullaridan biridir.

Draft pull request

Draft pull request — hali to‘liq tayyor bo‘lmagan, lekin oldindan ko‘rsatish yoki muhokama qilish uchun ochilgan pull request.

Draft pull request quyidagi holatlarda ishlatiladi:

• ish hali davom etayotgan bo‘lsa;
• erta fikr olish kerak bo‘lsa;
• CI/CD natijasini oldindan ko‘rish kerak bo‘lsa;
• arxitektura yoki yondashuv muhokama qilinsa;
• katta o‘zgarish bosqichma-bosqich tayyorlansa.

Draft holatidagi pull request odatda tayyor deb hisoblanmaydi.

Open pull request

Open pull request — hali yopilmagan va merge qilinmagan pull request. Open holatdagi pull request ustida review, test, muhokama yoki qo‘shimcha commitlar davom etishi mumkin.

Open pull requestda quyidagilar bo‘lishi mumkin:

• kutilayotgan review;
• failed testlar;
• conflict;
• qo‘shimcha commitlar;
• request changes;
• approval;
• merge kutayotgan holat.

Open pull request repositorydagi faol ish jarayonini bildiradi.

Closed pull request

Closed pull request — merge qilinmasdan yopilgan pull request. Bunday holatda o‘zgarishlar target branchga qo‘shilmaydi.

Pull request quyidagi sabablar bilan yopilishi mumkin:

• o‘zgarish kerak bo‘lmay qolgan;
• noto‘g‘ri branchdan ochilgan;
• boshqa pull request bilan almashtirilgan;
• loyiha yo‘nalishi o‘zgargan;
• kod alohida usulda qo‘shilgan.

Closed pull request tarixi platformada saqlanib qoladi.

Merged pull request

Merged pull request — target branchga qo‘shilgan pull request. Bu holatda pull requestdagi o‘zgarishlar asosiy kod tarixining bir qismiga aylanadi.

Merged pull requestda quyidagilar bo‘ladi:

• merge vaqti;
• merge qilgan foydalanuvchi;
• qo‘shilgan commitlar;
• target branch holati;
• linked issue yopilishi mumkin;
• CI/CD jarayoni ishga tushishi mumkin.

Merged holat pull request muvaffaqiyatli yakunlanganini bildiradi.

Linked issue

Pull request issue bilan bog‘lanishi mumkin. Bu orqali pull request qaysi vazifa, bug yoki taklifga tegishli ekanini ko‘rsatadi.

Linked issue quyidagi holatlarda ishlatiladi:

• pull request ma’lum bugni tuzatsa;
• feature issue asosida yozilsa;
• task bajarilganini ko‘rsatsa;
• issue avtomatik yopilishi kerak bo‘lsa;
• loyiha boshqaruvi bilan bog‘lanish kerak bo‘lsa.

Masalan, pull request description ichida Closes #25 yozilsa, merge qilingandan keyin 25-raqamli issue yopilishi mumkin.

Label

Label — pull requestni turkumlash uchun ishlatiladigan belgi. Label pull request mazmuni yoki holatini ko‘rsatadi.

Pull request label misollari:

• bug;
• feature;
• frontend;
• backend;
• documentation;
• refactor;
• security;
• needs review;
• ready to merge.

Label repositorydagi pull requestlarni tartibli ko‘rishga yordam beradi.

Assignee

Assignee — pull request uchun mas’ul foydalanuvchi. Assignee odatda shu pull request ustida ishlayotgan yoki uni boshqarayotgan shaxsni bildiradi.

Assignee quyidagi maqsadlarda ishlatiladi:

• mas’ul dasturchini ko‘rsatish;
• ish kimga tegishli ekanini bildirish;
• review yoki tuzatish jarayonini kuzatish;
• jamoa ichidagi vazifalarni ajratish.

Pull requestga bir yoki bir nechta assignee biriktirilishi mumkin.

Milestone

Milestone — pull requestni ma’lum release, sprint yoki loyiha bosqichi bilan bog‘lash uchun ishlatiladi.

Milestone quyidagi holatlarni ifodalaydi:

• v1.0 release;
• navbatdagi sprint;
• beta versiya;
• production release;
• roadmap bosqichi.

Milestone ichida issue va pull requestlar birgalikda jamlanishi mumkin.

Branch protection

Branch protection — muhim branchlarni bevosita o‘zgartirishdan himoya qiladigan sozlama. Pull request ko‘pincha branch protection bilan birga ishlatiladi.

Branch protection orqali quyidagilar talab qilinishi mumkin:

• pull request orqali merge qilish;
• kamida bitta approval olish;
• status checks muvaffaqiyatli o‘tishi;
• conflict bo‘lmasligi;
• administrator tasdig‘i;
• force pushni bloklash.

Masalan, main branchga to‘g‘ridan-to‘g‘ri push qilish taqiqlanib, faqat pull request orqali o‘zgarish kiritilishi mumkin.

Forkdan pull request

Open-source loyihalarda foydalanuvchi original repositoryga bevosita push qila olmasligi mumkin. Bunday holatda repository fork qilinadi va pull request forkdan ochiladi.

Jarayon:

• repository fork qilinadi;
• fork ichida branch yaratiladi;
• o‘zgarish commit qilinadi;
• forkdagi branchdan original repositoryga pull request ochiladi;
• maintainerlar kodni ko‘rib chiqadi;
• tasdiqlansa, original repositoryga merge qilinadi.

Bu open-source hissa qo‘shish jarayonida ko‘p uchraydi.

Maintainer

Maintainer — repositoryni boshqaradigan va pull requestlarni ko‘rib chiqadigan asosiy mas’ul shaxs yoki jamoa. Maintainerlar repository holati, kod sifati va merge jarayonlarini boshqaradi.

Maintainer quyidagi amallarni bajarishi mumkin:

• pull requestni review qilish;
• reviewer tayinlash;
• label qo‘shish;
• issue bilan bog‘lash;
• merge qilish;
• pull requestni yopish;
• branch protection sozlash;
• release tayyorlash.

Open-source loyihalarda maintainerlar tashqi hissa qo‘shuvchilardan kelgan pull requestlarni ko‘rib chiqadi.

Pull request va Git farqi

Pull request Git’ning bevosita ichki buyrug‘i emas. U GitHub, GitLab va boshqa platformalarda Git branchlari ustida ishlaydigan hamkorlik mexanizmidir.

Farqlar:

• Git branch, commit, merge va repository bilan ishlaydi;
• Pull request platformadagi muhokama va review jarayoni;
• Git’da git merge buyrug‘i bor;
• Pull request esa merge qilishdan oldingi tekshiruv qatlamini beradi;
• Git local muhitda ishlaydi;
• Pull request remote platformada yuritiladi.

Masalan, branchni merge qilish Git amali, lekin pull request orqali merge qilish GitHub’dagi jamoaviy jarayondir.

GitHub va GitLab’da nomlanishi

Pull request atamasi GitHub va Bitbucket’da ishlatiladi. GitLab’da shunga o‘xshash tushuncha Merge request deb ataladi.

Platformalardagi nomlar:

• GitHub — Pull request;
• Bitbucket — Pull request;
• GitLab — Merge request;
• Azure DevOps — Pull request.

Nomlari farq qilsa ham, asosiy vazifa branchdagi o‘zgarishlarni ko‘rib chiqib, boshqa branchga qo‘shishdan iborat.

Pull request hayot sikli

Pull request odatda bir nechta bosqichdan o‘tadi.

Asosiy bosqichlar:

• branch yaratish;
• kod yozish;
• commit qilish;
• branchni push qilish;
• pull request ochish;
• review;
• status checks;
• tuzatishlar;
• approval;
• merge;
• branchni yopish yoki o‘chirish.

Bu jarayon repositorydagi o‘zgarishlarni tartibli boshqarishga yordam beradi.

Dasturlashdagi o‘rni

Pull request zamonaviy dasturlash jarayonida jamoaviy ishlash, kod sifati va asosiy branch barqarorligini saqlash uchun muhim mexanizm hisoblanadi.

Pull request quyidagi joylarda ishlatiladi:

• jamoaviy frontend loyihalar;
• backend loyihalar;
• open-source loyihalar;
• DevOps konfiguratsiyalari;
• dokumentatsiya o‘zgarishlari;
• CI/CD jarayonlari;
• code review;
• release tayyorlash;
• hotfix jarayonlari;
• enterprise development.

Pull request branchdagi o‘zgarishlarni ko‘rib chiqish, tekshirish va nazorat bilan merge qilish jarayonini tashkil qiladi.

Bog‘liq tushunchalar

Git, GitHub, GitLab, Repository, Branch, Commit, Merge, Code review, CI/CD, Issue, Fork, Status checks