AXV

Pull Request va Merge konfliktlar

Kodni jamoaga to'g'ri taqdim etamiz va ziddiyatlarni xotirjam hal qilamiz

11-sinfProfessional IT development2-hafta · 5-dars

Bugun nimani o'rganamiz?

PR madaniyati

What, Why, How va dalillar bilan boyitilgan tavsif

PR shabloni

.github/pull_request_template.md va checklist

Merge va konflikt

Uch xil strategiya va ziddiyatni qo'lda yechish

Takrorlash: 4-dars

Nega alohida tarmoq?

bosing

Yangi kod main'ni buzmasligi uchun: tajriba alohida tarmoqda yoziladi.

git switch -c feat/my-feature

bosing

Yangi tarmoq yaratadi va darhol unga o'tadi.

Conventional commit

bosing

Tur, qamrov va qisqa tavsif: masalan feat(auth): add login.

01

Pull Request anatomiyasi

Taklifdan asosiy tarmoqqa qo'shilishgacha

Pull Request nima?

PR — o'z tarmog'ingdagi o'zgarishlarni main'ga birlashtirishni so'rab jamoaga yuboriladigan rasmiy taklif.
Muhokama maydoni Sifat eshigi: CI, linter, skaner Loyiha tarixi
PR shunchaki birlashtirish tugmasi emas: u jamoaviy nazorat.

PR hayotiy sikli

1. Push feature branch 2. Open PR What/Why/How Closes #N 3. Review CI testlar Approve 4. Merge main yangilanadi Issue yopiladi

Bosqichlar ustiga bosing: izoh chiqadi.

Professional PR: Why / What / How

Why? Nega?

Qaysi muammo yoki Issue yopilmoqda? Closes #14

What? Nima?

Aynan nimalar o'zgardi: qisqa punktlar.

How? Qanday?

Arxitektura qarori, algoritm yoki baza o'zgarishi.

«Kod yozdim» degan bo'sh tavsif bilan PR ochilmaydi.

Issue'ni avtomatik yopish


## Nega kerak?
Profil sahifasidagi xatoni tuzatadi.
Closes #15
    
PR merge bo'lishi bilan #15 Issue avtomatik yopiladi.

Pastga bosing: boshqa kalit so'zlar

Kalit so'zlar

Closes #12

Vazifani yopadi

Fixes #25

Xatoni tuzatganini bildiradi

Resolves #89

Muammo hal bo'lganini bildiradi

Dalillash madaniyati (Evidence)

Oldin / Keyin

Skrinshot yoki qisqa GIF ilova qilinadi: reviewer loyihani yig'ib o'tirmaydi.

Log va testlar

Terminal logi yoki muvaffaqiyatli test skrinshoti ilova qilinadi.

Dalil bor joyda munozara qisqa bo'ladi.
02

PR shabloni va checklist

Hamma bir xil standartda yozadi

PR shabloni qanday ishlaydi?

.github/ pull_request_template.md ## Tavsif - [ ] Testlar o'tdi Open a pull request Tavsif oynasi avtomatik to'ladi Siz javob yozasiz

Qismlarni bosing yoki ustiga olib boring.

pull_request_template.md


## Tavsif (Description)
<!-- Ushbu PR nima qiladi? -->
## Nima uchun kerak? (Why)
<!-- Masalan: Closes #12 -->
## Asosiy o'zgarishlar
-
## Tekshiruv ro'yxati (Checklist)
- [ ] Kod uslubi (linter) tekshirildi
- [ ] Lokal testlar muvaffaqiyatli o'tdi
- [ ] Maxfiy ma'lumotlar (.env) yo'qligi tekshirildi
    

Pastga bosing: faylni repoga qo'shamiz

Shablonni repoga qo'shish


mkdir -p .github
nano .github/pull_request_template.md
git add .github/pull_request_template.md
git commit -m "chore(github): add pull request template"
git push origin main
    

Kichik PR qoidasi

0
10 muhandis sinchiklab tekshiradi
0
hamma «Looks good to me» deydi
0
ideal PR shundan oshmaydi
Katta PR: xatolar ko'zdan qochadi, konflikt ehtimoli oshadi.
03

Merge turlari va konfliktlar

Squash, Rebase va ziddiyatlarni yechish

Uch xil merge strategiyasi

Merge commit Tarix to'liq saqlanadi + Merge commit Squash and merge Eng mashhuri Bitta toza commit Rebase and merge Chiziqli tarix Merge commit yo'q

Ustiga bosing: tafsilot.

Squash: 15 xom commit, 1 toza commit

Feature'da

«tuzatdim», «yana xato», «ishladi»...
VS

main'da

feat: implement user settings

Pastga bosing: qachon qaysi biri?

Qachon qaysi biri?

Squash

Odatiy zamonaviy standart: feature kichik va toza

Merge commit

Katta subsystem relizlari, Git Flow'da develop ni main'ga qo'shish

Rebase

Tarix qat'iy chiziqli bo'lishini xohlovchi jamoalar

Merge conflict qanday ko'rinadi?

<<<<<<< HEAD (main) return db.find(user_id) ======= return cache.get(user_id) >>>>>>> feat/cache-users Git tanlay olmaydi: siz tanlaysiz

Yuqori va pastki blokni bosing.

Konfliktli fayl


<<<<<<< HEAD
host = "localhost"
=======
host = "127.0.0.1"
>>>>>>> feat/network
  

Yechilgan fayl


host = "127.0.0.1"
  
Belgilar o'chirildi: endi git add va git commit.

Konfliktni yechish: 4 qadam

1. Muharrirda oching

VS Code yoki boshqa muharrirda konfliktli faylga qarang.

2. Mantiqni tanlang

Ikkala qismni tahlil qiling va to'g'ri kodni belgilang.

3. Belgilarni o'chiring

<<<<<<<, =======, >>>>>>> qatorlarini qo'lda olib tashlang.

4. add va commit

git add fayl, so'ng git commit: merge yakunlanadi.

Konflikt laboratoriyasi


git switch -c feat/update-text
echo "Versiya 2.0 - feature" > app.txt
git commit -am "feat: update line"
git switch main
echo "Versiya 1.5 - main" > app.txt
git commit -am "fix: hotfix on main"
git merge feat/update-text
# CONFLICT (content): Merge conflict in app.txt
echo "Versiya 2.0 - kelishuv" > app.txt
git add app.txt
git commit -m "merge: resolve conflict"
  

GitHub'dagi toza PR

github.com/org/repo/pull/24

feat(auth): add google oauth login #24

Open · dev wants to merge 3 commits into main from feat/auth

Why: Closes #14 · What: login tugmasi, callback · Checks: 2 successful

Tezkor savol

Feature'dagi 10 ta commit main'ga bitta toza commit bo'lib tushishi uchun qaysi strategiya tanlanadi?

To'g'ri: Squash and merge barcha commitlarni bitta toza commitga siqadi va main tarixini tartibli saqlaydi.

Amaliyot 20 daqiqa

Oson.github/pull_request_template.md shablonini yarating va push qiling.
O'rtaKonflikt laboratoriyasi: ataylab konflikt hosil qiling va VS Code'da yeching.
QiyinGitHub'da What/Why/How asosida PR oching, Closes #N yozing.

Bugun nimani bildik?

PR

Muhokama va sifat eshigi

Tavsif

Why, What, How, dalil

Squash

Toza tarix uchun

Konflikt

Qo'lda uyg'unlashtiramiz

Keyingi dars: Code Review

6-dars: PR'larni professional tahlil qilish, inline sharhlar, taklif kodi va Branch Protection.

Pastga bosing: Bilasizmi?

Bilasizmi?

2008-yil

PR tushunchasini GitHub joriy qilgan. Undan oldin o'zgarishlar elektron pochta orqali .patch fayl bo'lib yuborilgan.

Botlar ham ko'radi

Zamonaviy loyihalarda inson ko'rib chiqishidan oldin botlar PR'dagi xatolarni topib, sharh qoldiradi.