Git: Branch (filial) yaratish va o'zgarishlarni Merge (birlashtirish) qilish

Ushbu pleylist Git va versiyalarni boshqarish (Source Control) haqida, va hozirgacha biz repozitoriyani clone qildik, repozitoriyaga commit qildik, o'zgarishlarni stage qildik, o'zgarishlarni stash qildik, va oldingi videoda esa o'zgarishlarni push va pull qilishni o'rgandik. Versiyalarni boshqarish uchun juda muhim bo'lgan, ammo hali qilmagan narsamiz — branching (filiallash). Ushbu videoda biz aynan shu haqida gaplashamiz: branching, asosan, kod bazasini olib, uni shoxlash (branch qilish), degani — bu, aslida, kod bazamizning boshqa bir versiyasi, ya'ni asosiy (main) versiya va shoxlangan (branched) versiya bir vaqtning o'zida mavjud bo'ladi. Kod bazamning ikkinchi versiyasiga ega bo'lganim sababli, men endi shu branch'da asosiy versiyaga ta'sir qilmaydigan ko'plab o'zgarishlar qila olaman — masalan, biror xususiyat ustida ishlashim, biror kod bilan tajriba o'tkazishim mumkin, va shu o'zgarishlarni asosiy versiyaga qaytarib qo'shishga tayyor bo'lganimda, ularni merge qilaman.

Demak, avval biz yon (side) branch'ga shoxlanamiz, so'ngra esa asosiy branch'ga qaytib merge qilamiz — ushbu video aynan shu haqida bo'ladi: qanday qilib branch'lash va qanday qilib merge qilish. Ushbu pleylistdagi boshqa barcha narsalar kabi, biz ushbu videoda asoslarni o'rganamiz, va shundan keyin buni kelgusi barcha videolarda ishlatamiz. Branch'lash bo'yicha yaratishingiz mumkin bo'lgan branch'lar sonida hech qanday cheklov yo'q — bu, asosan, kodingiz va loyihangiz versiyalarini boshqarish uchun bir vosita, xolos. Kerak bo'lganda, xohlaganda branch yarating — bu yerdagi maqsad, yangi xususiyatlar yozish va qurish jarayonida sizning samaradorligingizni oshirish.

Branch nima

Avval shu diagrammani ko'rib chiqaylik: Master — bu main, hozir esa ko'pchilik buni "main" deb ataydi (ilgari ba'zilar "Master" deb atashar edi), ammo asosiy branch yashil rangda. Hozircha shu commit'larning hech biri yo'q deb tasavvur qiling, va biz shunchaki shu boshlang'ich commit'dagimiz — bitta master branch, biz aynan shu yerdamiz. Asosiy branch, asosida, bizning Master Branchimiz: production'ga push qilinadigan har qanday narsa aynan shu yerda bo'lishi kerak — bu bizning haqiqat manbai (source of truth) bo'ladi.

Shuning uchun, kod yozayotganimizda, ko'pincha biz to'g'ridan-to'g'ri master yoki main branch'ga commit qilmaymiz. Hozirgacha bizning barcha commit'larimiz asosiy branch'ga tushgan, va agar siz hozirgina boshlagan bo'lsangiz, o'z shaxsiy loyihangiz ustida ishlayotgan bo'lsangiz, to'g'ridan-to'g'ri main'ga commit qilishingiz mumkin, bu butunlay normal. Ammo kattaroq ilovada, production ilovasida, yoki kattaroq jamoada, sizda main branch bo'ladi, va bundan tashqari boshqa yon branch'lar ham bo'ladi — har bir kishi o'z shaxsiy ishini shu yon branch'larda olib boradi, va u tayyor bo'lganida, biz buni asosiy branch'ga yoki release branch'ga merge qilamiz.

Demak, ko'p hollarda siz to'g'ridan-to'g'ri main branch'da ishlamaysiz — siz boshqa bir branch'da ishlaysiz, va oxir-oqibatda, bu yakunlanganida, foydalanuvchilarga yetganida, biz buni asosiy branch'ga merge qilamiz. Buning haqida pleylistning oxiriga yaqin, git flowni ko'rib chiqayotganimizda, ancha batafsil gaplashamiz, ammo hozircha sizlardan shuni tushunishingizni xohlayman: branch'lar mavjud, master yoki main branch bor, ammo ko'pincha bo'ladigan jarayon shu: biz branch'lashamiz, shu yerda barcha ishimizni qilamiz, va tugagandan keyin buni qaytib asosiy branch'ga merge qilamiz.

Birinchi branch'ni yaratish

Keling, birinchi branch'imizni yaratishdan boshlaylik. Avval Xcode'da qilamiz — hozircha men main branch'da ekanligimni ko'rishim mumkin. Main branch'ga borib, uchta nuqtani (...) bossam, main branch'dan yangi branch yaratishim mumkin — bu, aynan diagrammada ko'rganimizdek: biz hozir shu yerdamiz, va branch yaratmoqdamiz, aynan Xcode'da ham xuddi shuni qilmoqdamiz. Buni Source Control Navigatorga o'tib, Main'ga o'ng tugmani bosib, "New Branch" orqali ham qilishimiz mumkin.

Yangi branch yaratganda ba'zi nomlash konventsiyalari bor, ammo hozircha buni shunchaki my-second-branch deb ataman (branch nomlaganimda, odatda bo'shliq va maxsus belgilarni ishlatishni xohlamayman — buni sodda qilib qoldiraylik). Branch'ni yaratamiz.

Endi ko'ramiz: bu yangilanmadi — kutib turing, shu branch'ga o'tishim kerak edi, men allaqachon shu yerda bo'lishim kerak edi, nimagadir bilmadim nega bo'lmadi — Xcode'ning Source Control'i ba'zan biroz g'alati ishlashi mumkin. Ammo endi men my-second-branchdamiz — bu bizning hozirgi branch'imiz, main branch emas, va buni yuqorida my-second-branch deb ko'rishim mumkin, shuning uchun qaysi branch'da ekanligimni aniq bilaman.

Ikkalasi orasida bossam, ularning aynan bir xil commit tarixiga ega ekanligini ko'raman, chunki bu — bir xil narsa; hozircha men ikkinchi branch'ga main branch'da yo'q hech narsa qo'shmadim.

GitKraken'da branch'ni ko'rish

GitKraken'da ham buni ko'rishim mumkin: main branch hamda my-second-branch'ni ko'raman, va payqaysiz: main branch'da mening GitHub akkauntim uchun kichik bir belgicha bor, my-second-branch'da esa yo'q. Bu menga shuni bildiradi: hozircha mening ikkinchi branch'im faqat lokal (local), u remote (uzoq) emas. Agar pastdagi remote repo'ga qarasam, main branch'ni ko'raman, ammo my-second-branch yo'q — demak, my-second-branch aniq faqat lokal bo'lishi kerak.

Ko'pincha, branch yaratishim bilan, men buni darhol GitHub'ga ham push qilmoqchi bo'laman. Shuning uchun remote repo'ga endi bizda ikkinchi branch borligini, va u haqiqatan ham mavjudligini bildiraylik. My-second-branch'da bo'lganimiz holda, buni remote repo'ga push qilaylik — bu yerda haqiqatan ham "create" deb yozilganini ko'rasiz, u bu branch remote repo'da yo'qligini biladi, va hozir uni yaratishi kerak bo'ladi. Keling, shuni push qilaylik.

GitKraken'ga qarasak, ikkalasi ham endi ham lokal, ham remote'da ekanligini ko'ramiz — shuningdek, remote tomonimda ham endi my-second-branch borligini ko'rishim mumkin. Agar GitHub'ni qayta ochsam, repo'imga qaytib qarasam, endi haqiqatan ham ikkita branchni ko'rishim kerak: main branch hamda my-second-branch. Bu yerga bossam, yoki barcha branch'larni ko'rishim mumkin — bu juda qulay ko'rinish, chunki bu bizga faol branch'larni ko'rsatadi, chunki ba'zida eskirgan (stale) branch'lar bo'ladi. Tasavvur qiling: biror branch yaratdingiz, uni unutdingiz, bu loyihani unutdingiz, sakkiz oydan beri hech kim shu branch'ga tegmagan — bu hamon mavjud, ammo endi eskirgan. Bu kichik bo'lim, agar sizda ko'plab jamoa a'zolari bo'lgan katta loyiha bo'lsa, juda foydali — shu yerga kirib, faol branch'lar qaysilar ekanligini, kim qaysi branch'da ishlayotganini ko'rishingiz mumkin: bu kishi besh branch ustida ishlayapti, bu kishi boshqasi ustida, va shu branch'lar asosiy branch'dan qancha oldinda yoki orqada ekanligini ham ko'rishingiz mumkin.

Branch'da ishlash va o'zgarishlarni push qilish

Xcode'ga qaytaylik. Bu — odatdagi ish jarayoni: men main'dan branch'layman, biror ish qilaman, va oxir-oqibatda, shu ishni qaytib asosiy branch'ga merge qilishga tayyor bo'laman. Ammo shu ikki branch'ga ega bo'lganimda, qiziq tomoni shunda: ular orasida almashtirib turishim mumkin — masalan, GitKraken'da Main'ga ikki marta bosib, main branch'ga o'tishim mumkin; ikki marta bosib, yana qaytib o'tishim mumkin. Xcode'da ham, shunchaki o'ng tugmani bosib, switch qilishim mumkin (agar eski Xcode versiyasida bo'lsangiz, bu checkout deb ataladi — bu, asosan, boshqa branch'ni "tekshirib chiqish" (check out), do'kondagi kassa kabi).

Asosiy branch'ga o'tamiz — switch qilamiz, va endi men main branch'damiz. My-second-branch'ga qaytib o'taman.

Endi shu yerda biroz kod yozaylik — masalan, yana bir to'rtburchak (Rectangle) qo'shmoqchiman. Va tasavvur qiling: menejerim kelib, "Nik, hozir nima qilayotgan bo'lsang, to'xtat, men production'dagi kodga qarab, shu analitika qanday ishlashini ayt" desa — masalan, men main branch'dagi versiyani ko'rmoqchiman. Shuning uchun shu kodni ko'rish uchun main branch'ga o'tmoqchiman, ammo o'tishga harakat qilganimda, boshqa bir xabar olaman: stash changes (o'zgarishlarni stash qilish). Aynan shuning uchun men avval stash haqida video qilgan edim — chunki agar bizda tugallanmagan o'zgarishlar bo'lsa, biz bir branch'dan boshqasiga o'ta olmaymiz, chunki tizim bu o'zgarishlar bilan nima qilishimizni bilishi kerak: ularni butunlay tashlab yuboramizmi, yoki ularni qayergadir stash qilamizmi.

Shuning uchun men hozir shu o'zgarishlarni stash qilib, so'ngra o'tishim, yoki bu o'zgarishlarni tashlab, so'ngra o'tishim mumkin — yoki Xcode'ga buni o'zim uchun bajartirishim mumkin: shunchaki o'ng tugmani bosib, switchni tanlasam, va u so'raganida, shu yerga "adding second rectangle" deb yozib, bir vaqtning o'zida ham stash, ham switch qilaman. Endi u mening stash'imni yaratib, meni main branch'ga o'tkazib qo'ydi. Endi my-second-branch'ga qaytib, shu stashimni qo'llashim (apply) mumkin — bu stash menga endi kerak emas, keyinroq o'chiraman, ammo hozircha shunchaki apply qilaman, va biz yana avvalgi holatga qaytamiz.

Buni yana bir bor GitKraken'da ham qilaman — shu o'zgarish bilan main'ga o'tmoqchi bo'lsam, bu menga ruxsat bermaydi — u "avval o'zgarishlaringizni stash qiling yoki commit qiling" deb aytadi, aynan biz hozirgina gaplashgan narsa. Shuning uchun o'zgarishlarimizni stash qilamiz, so'ngra branch'lar orasida o'tamiz — va endi o'tdik, va ko'ramiz: shu stash yuqorida qaytadan paydo bo'ldi. Yana shu yerga qaytib, my-second-branch'ga o'tamiz.

Branch'ni main'ga Merge qilish

Demak, biz branch yaratishni va branch'lar orasida o'tishni o'rgandik — endi videoni yengil bir merge qilish bilan yakunlaymiz. Shu branch'da barcha ishimni qilganimdan keyin — ehtimol yangi bir xususiyat qurayotgan, yoki boshqa biror narsa qilayotgan bo'lsam — endi men buni qaytib asosiy repo'ga merge qilishga tayyorman, chunki, ehtimol, jamoamdagi barcha dasturchilar aynan shu asosiy main holatdan ishlamoqda, ammo jamoamdagi boshqa dasturchilar mening shu branch'da nima qilayotganimni bilishmaydi — ular mening commit'larimni ko'rishlari mumkin, ammo ular bu xususiyatni qurmayapti, ular, ehtimol, o'z branch'larida o'z ishlarini qilishmoqda. Shuning uchun qaysidir vaqtda biz barcha o'zgarishlarimizni yakuniy mahsulotga birlashtirishimiz kerak bo'ladi.

Men my-second-branch'imni main branch'ga merge qilmoqchiman. Xcode'ga qaytamiz, my-second-branch'dayman, o'ng tugmani bosib, mergeni bosaman. Buni yuqoridan, Main'ga bosib, so'ngra mergega o'tib ham qilishim mumkin — ammo bu, aslida, biz xohlagan narsa emas, bu teskarisi: bu main'ni my-second-branch'ga merge qilish bo'ladi, biz esa my-second-branch'ni mainga merge qilmoqchimiz. Shuning uchun main branch'ga o'tib (checkout qilib), my-second-branch'ni main'ga merge qilmoqchiman. Diagrammamizga yana qarasak: biz hozir shu yerdamiz, va buni asosiy branch'ga merge qilishga harakat qilmoqdamiz — biz main branch'ning shu yerga kelishini emas, balki shu yerdagining main'ga kirishini xohlaymiz.

Keling, shuni tezda qilamiz: o'ng tugmani bosib, merge my-second-branch into mainni tanlaymiz. "O'zgarishlarni rostdan ham merge qilmoqchimisiz?" deb so'raydi — "Merge"ni bosamiz. Mana — my-second-branch endi main'ga merge qilindi. Buni GitKraken'da yaxshiroq ko'rishim mumkin: main endi yuqorida — men shu commit'larni olib, ularni main branch'ning lokal versiyasiga "uchirdim".

Yana eslatib o'tay: main lokalda va main remote'da — bu ikki xil narsa. Biz buni lokalda merge qildik, ammo remote'da emas, aynan shuning uchun main hozir remote repo'dan ikki commit oldinda. Shuning uchun har safar shu kabi narsalarni qilganimizda, buni haqiqatan ham push qilib, GitHub'ga ham integratsiya qilishimizga ishonch hosil qilishimiz kerak, shunda GitHub'imiz ham mos holatda qoladi. Endi hammasi yuqorida, bir holatda.

Merge qilingan branch'ni o'chirish

Odatda, merge qilgandan keyin, sizga shu branch endi kerak bo'lmaydi, shuning uchun uni o'chirib qo'yishingiz mumkin. GitKraken'da shunchaki my-second-branchni va origin/my-second-branchni o'chirishim mumkin — bu yerdagi farq shunda: origin — bu remote versiya, "origin"siz nom esa — lokal versiya. Shuning uchun branch'ni ham lokal, ham remote'da, yoki ulardan faqat birida o'chirishim mumkin. Xcode'da esa shunchaki o'ng tugmani bosib, deleteni tanlayman — "Bu branch'ni o'chirmoqchimisiz? U repo'dan olib tashlanadi" — "Delete"ni bosaman.

Endi shu stash'ni ham o'chirib, source control'imizni biroz tozalaymiz — endi bizda shunchaki main branch bor. Ammo payqaysiz: Xcode remote branch'ni o'chirmadi — shuning uchun qaysidir vaqtda GitHub'ni ochib, branch'larga kirib, shu branch'ni ham o'chirishimiz kerak bo'ladi. Ko'pincha merge'larni GitHub'ning o'zida amalga oshirasiz — shunda branch GitHub orqali merge qilinganda avtomatik ravishda o'chiriladi. Buning sababi shu: ko'plab merge'lar pull requestlarni talab qiladi — pull request'larni esa kelgusi bir videoda ko'rib chiqamiz, bunga alohida video kerak bo'ladi. Hozircha esa, shunchaki branch'lash va merge qilish haqida sodda tarzda gaplashamiz.

Branch'ladik, so'ngra merge qildik, va shu branch'ni o'chirganimizdan keyin, yangilanishlarni pull qilaylik (agar biror yangilanish bo'lsa) — va endi remote versiyani ham qandaydir tarzda o'chirishimiz kerakday tuyuladi, va endi biz qaytadan toza Source Control loyihasidamiz.

Payqaysiz: garchi biz branch'lab, so'ngra merge qilgan bo'lsak ham, men endi bu branch'ni umuman ko'rmayapman — bu g'oyib bo'lgan. Shu narsani ta'kidlab o'tmoqchiman: buni merge qilganimizda, biz shu ikki commit'ni asosiy branch tarixiga qo'shdik, shuning uchun endi bu yerda branch bo'lganini ham ko'rmaymiz — bu branch g'oyib bo'lgan, biz faqat shu merge'dan qolgan commit'larni ko'ramiz. Aynan shuning uchun commit'lar muhim bo'la boshlaydi: agar siz boshqa odamlarning branch'lariga merge qilayotgan bo'lsangiz, bu commit'lar endi ular ko'rayotgan bir xil tarixda paydo bo'ladi — bu "Dev Branch" kabi ko'rinmaydi, bu shunchaki "commit, commit, commit" bo'lib ko'rinadi. Shuning uchun, albatta, yaxshi commit xabarlari yozishimiz muhim.

Bir nechta branch bilan amaliyot

Keling, buni amaliyot qilaylik — bir nechta branch yarataylik. GitKraken'ning o'zida ham o'ng tugmani bosib branch yaratishim mumkin, ammo odatda buni Xcode orqali qilaman. Hozir Xcode'da main branch'dayman — o'ng tugmani bosib, yangi branch yarataman. Tasavvur qilaylik: men yangi bir ekran qo'shmoqchiman, shuning uchun buni feature/add-explore-view deb ataymiz. "Create"ni bosamiz — yangi branch'imiz bor, endi shu yerga biror narsa qo'shaylik: o'ng tugmani bosib, yangi fayl yarataman, SwiftUI View, buni ExploreView deb ataymiz, "Create"ni bosamiz, va shu yerda commit'ni feature: add explore viewga aylantiraman. Buni stage qilaman, commit qilaman.

GitKraken'da shu o'zgarishni ko'rishim mumkin — bu hali remote'ga push qilinmagan, shuning uchun buni remote repo'ga push qilishga ishonch hosil qilaylik (integrate va push). Demak, bizda yangi explore view qo'shilgan branch bor, men buni shu yerda ko'rishim mumkin, va u remote repo'ga ham push qilingan.

Ammo, ehtimol, mahsulot menejeringiz kelib: "Nik, bilaman siz hozir Explore View ustida ishlayapsiz, ammo bizga sizning main branch'ga o'tib, boshqa narsa uchun analitika qo'shishingiz kerak — bu yuqoriroq ustuvorlikka ega, hozirgi ishingizni to'xtatib, shuni qilishingiz kerak" deydi. Bu branch'ni o'chirib tashlashni xohlamayman — buni keyinroq davom ettiraman — shuning uchun main branch'ga o'taman. Xcode'da main branch'ga qaytamiz.

Endi main branch'dan yana bir branch yaratamiz: add-home-analytics deb ataymiz (new so'zi unchalik tasviriy emas, shuning uchun add-home-analyticsni tanlayman), "Create"ni bosamiz. Yana, bu faqat lokal va remote emas, shuning uchun integratsiya qilib, remote repo'ga push qilamiz — remote repo'da yaratamiz. Buni GitKraken'da ham, remote repo bilan birga ko'rishim mumkin.

Endi shu analitikani qo'shaylik: home view'ga o'tib, shunchaki, masalan, commit'ni feature: add home analytics deb belgilaymiz, stage qilamiz, commit qilamiz, remote repo'ga push qilamiz.

Endi menejeringiz yana kelib: "Nik, bilaman, siz shu analitikani qo'shyapsiz, ammo aslida ilovada crash (qulash) bor, va buni tezda tuzatishimiz kerak" deydi. Yaxshi, ilovamning main versiyasiga o'tamiz — main'ga qaytib o'taman. Qulash qayerda? Qulash ContentViewda — yaxshi, shuni o'zgartirishim kerak ko'rinadi. O'ng tugmani bosib, yangi branch yaratamiz: fix-user-subscribe-crash deb ataymiz (qulash aslida nima ekanligini bilmayman, men buni shunchaki misol uchun o'ylab topyapman). Shu yerdan ham remote repo'ga push qilishimizga ishonch hosil qilaylik — har doim remote'ga push qilish shart emas, ammo men buni ikkinchi zaxira nusxa sifatida saqlash uchun yoqtiraman. Endi kodimizni tuzataylik — masalan, shu qismni olib tashlab, tuzatamiz — biz production'da jonli bo'lgan narsani tuzatmoqdamiz.

Bir nechta branch'ni navbat bilan Merge qilish

Keling, shuni patch: fix subscribe buttondeb commit qilamiz (bu, albatta, haqiqiy crash emas, biz buni shunchaki simulyatsiya qilyapmiz), remote repo'ga push qilamiz.

GitKraken'ga qaytsak — men aynan shuning uchun GitKraken'ni haqiqatan ham yoqtirib qoldim: bu yerda turli branch'larni turli ranglarda aniq ko'rishingiz mumkin, va siz ancha murakkab, ko'plab boshqa odamlar bilan ishlaydigan repolarga kirganingizda, har bir kishining foydalanuvchi nomini, barcha branch'larni ko'rishingiz mumkin — branch'lar rang bo'yicha kodlangan, shuning uchun bu juda foydali bo'ladi, Xcode'da esa bizda faqat shu bor — biz o'zgarishlarni, turli branch'larni ko'rishimiz mumkin, ammo shu branch'larning yuqori darajadagi xronologiyasini ko'rish ancha qiyin.

Mayli, endi bizda bir nechta turli branch bor — keling, ularni merge qilish bo'yicha amaliyot qilaylik. Main'ga qaytib o'tamiz — endi main branch'dаmiz. Avval subscribe branchimizni merge qilaylik: o'ng tugmani bosib, merge fix-user-crash into mainni tanlaymiz — umid qilamiz, ishlaydi. add subscribe button endi shu commit tarixida. Xuddi shunday analytics uchun ham qilaylik: merge analytics into mainni tanlab, merge qilamiz.

Buning ishlaganini tekshiramiz — main'ni qaytadan GitHub'ga push qilamiz, chunki bu o'zgarishlar, bu merge'lar hali GitHub'ga push qilinmagan. Bu yerda mening main branch'im qayerda ekanligini ko'rishim mumkin, va home analytics main branch'ga merge qilinganini ko'raman. Shuningdek, fix user crash ham main branch tarixida ekanligini ko'rishim mumkin — bu biroz boshqacha ko'rinadi, chunki unda bu egilgan chiziq yo'q, ammo bu ham merge qilingan, bu ham merge qilingan. Bu kettlik xronologik tartibga asoslangan: agar main branch'ning xronologiyasiga qarasak — bu commit, bu commit, bu birinchi yaratilgan, ammo bu undan keyin yaratilgan, ammo biz buni avval main branch'ga merge qildik, bu esa ikkinchi bo'lib merge qilindi. Mayli, keling, buni GitHub'ga push qilaylik, shunda biz buni remote'da ham qo'lga kiritamiz.

Buni qilayotganimizda, bizga endi shu boshqa ikkita branch kerak emas — shuning uchun merge qilingan ikkalasini ham o'chiraman: o'ng tugmani bosib, deleteni tanlayman — ham lokal, ham remote versiyani. Xuddi shunday analytics uchun ham.

Bizda hamon add-explore-view qo'shmagan versiyamiz bor. Bu yana, Xcode'ning yangilanishlardan o'zini yangilamaganiga misol — GitKraken'ga qaytaylik. Xcode'ni yopib, tezda qaytadan ishga tushiraman, umid qilamanki, source control endi yangilanadi — endi ekranda faqat add-explore-view bor.

Branch'larni papka (folder) bilan tashkillash

Videoni yakunlashdan oldin yana bir nechta narsani qilishimiz kerak. Avval biz bir nechta branch yaratdik, ammo payqagan bo'lsangiz, bu branch'larning barchasi shunchaki shu yerda ro'yxat qilingan edi. Ammo tasavvur qiling: jamoangizda 50 ta muhandis bo'lsa, har bir kishi o'z branch'larini yaratayotgan bo'lsa, va hatto sizning o'zingiz ham har bir qo'shgan xususiyat uchun, har bir tuzatgan xato uchun, har bir narsa uchun yangi branch yaratishingizni tasavvur qiling — har bir kishida juda ko'plab branch bo'lishi mumkin. Shuning uchun ko'plab jamoalar, ayniqsa kattaroq jamoalar, branch yaratayotganda, shu yerga papka nomi ham qo'shadi. Men o'z bosh harflarimdan foydalanaman — ko'plab jamoalar o'z bosh harflaridan foydalanadi: NS, va buni add-some-feature deb ataymiz, "Create"ni bosamiz.

Endi NS bilan boshlanadigan barcha branch'lar shu NS papkasi ichida bo'ladi — bu oddiy branch yaratishdan farq qilmaydi, source control'da boshqacha ko'rinmaydi, ammo Xcode'da bu branch'larni dasturchi bo'yicha tartibli saqlashga yordam beradi — katta jamoalarda har bir kishi o'z bosh harflariga ega bo'ladi, va barcha branch'lari shu kichik papkada bo'ladi.

Keling, yana bittasini yarataylik — bu safar add-some-featuredan ham branch'laymiz: yangi branch yaratamiz, yana NS qo'shamiz, va secondni qo'shamiz — buni my-second-feature deb ataymiz (men bu yerda pastki chiziqcha ishlatishni yoqtiraman, siz xohlagancha nomlashingiz mumkin, men maxsus belgilar va bo'shliqdan qochishni tavsiya qilaman), "Create"ni bosamiz. Endi ko'ramiz: barcha branch'larim bir xil papkada — ko'plab jamoalar, ayniqsa dasturchilar mustaqil ishlayotganida, aynan shunday qiladi: men shu yerlarda ishlasam, branch'larimni shu yerda ko'rishim mumkin, boshqa kishi ishlasa, ular o'z papkasi va branch'lariga ega bo'ladi.

Ammo ba'zan, ehtimol, bir nechta dasturchi bir xil xususiyat ustida ishlaydi — demak, bu mening shaxsiy branch'imda ishlash emas, balki, masalan, besh dasturchi bir xil xususiyat ustida ishlaydi. Shuning uchun shu birini yaratganimizda, features deb nomlangan papkadan foydalanamiz, va shundan keyin some-new-feature deb yozib, "Create"ni bosamiz. Endi xususiyat ishlab chiqish bilan bog'liq barcha narsa shu papkaga tushadi.

Yana bir branch yarataylik: releases papkasi, masalan release-1.0.0 — release'larni kelgusi bir videoda ko'rib chiqamiz, hozircha buni amalda qilmaymiz, ammo keyinchalik release qiladigan har qanday branch yaratganimda, buni releases papkasiga qo'yishim mumkin — shunday qilib branch'larimni tashkillashtirishni boshlashim mumkin.

Demak, ba'zi jamoalar dasturchi bosh harflaridan foydalanadi, ba'zilari esa xususiyat (feature) bo'yicha tashkillaydi — men hatto shu yerdan sub-branchlar (kichik filiallar) ham yaratishim mumkin: yangi branch yaratib, hozirgi branch'dan shoxlanaman, va feature/new-onboarding-flow/add-first-screen deb ataman. Demak, endi bizda barcha xususiyatlarimni joylashtiradigan feature papkamiz bor, va ichida har bir xususiyat uchun alohida papka bo'ladi — masalan, onboarding ham bitta xususiyat bo'ladi, va yangi onboarding bilan bog'liq barcha branch'lar shu papkada bo'ladi. Demak, papkalaringizni qanday tuzishingiz unchalik muhim emas — muhimi shu: tartibli bo'lib qolishingiz, chunki jamoangiz qancha katta bo'lsa, branch'lar shuncha ko'p bo'ladi, va sizga shuncha ko'p tuzilma kerak bo'ladi. Ko'plab kattaroq jamoalarda, xuddi commit xabarlari yozish uchun bir metodologiya bo'lgani kabi, qachon va qanday branch'lash kerakligi haqida ham qoidalar bo'ladi.

Sinov branch'larini tozalash

GitKraken'ga qaytaylik — barchasi bir qatorda ekanligini ko'raman, ammo bularning hech biri menga aslida kerak emas, shuning uchun barchasini o'chiraman. Main branch'ga qaytamiz: add-first-screenni o'chiramiz, add-explore-viewni o'chiramiz, feature/some-new-feature bizga kerak emas — o'chiramiz, NS/add-some-featureni ham o'chiramiz, my-second-featureni ham o'chiramiz, va nihoyat, releasesni ham o'chiramiz (yana ta'kidlab o'tay: release'larni kelgusi videoda ko'rib chiqamiz).

Buni o'chirishni xohlayman, ammo hozircha o'chira olmayapman — Xcode'ni qaytadan ishga tushiraman, ehtimol bu yordam beradi. Repolarni qaytadan ochsam — ha, o'sha papkalar yo'qolgan. feature/add-explore-viewni remote repo'dan o'chirmagan ekanmiz, shuning uchun buni ham o'chiraylik — endi remote'dan ham o'chirildi. O'chirilganga o'xshaydi, ammo Xcode buni yangilamaganga o'xshaydi — Xcode ba'zan biroz buglik ishlaydi, shuning uchun yo uni qaytadan ishga tushirishimiz, yoki "refresh file status"ni bosishimiz mumkin — bu kodingizni yangilashi kerak. Endi men yana main branch'damiz.

Xulosa

Ushbu videoda biz branch'lash hamda merge qilish haqida o'rgandik, ammo bizda hech qanday merge konflikti bo'lmadi. Shuning uchun, merge qilishga harakat qilganingizda, bu allaqachon commit qilingan boshqa o'zgarishlar bilan to'qnashishi mumkin bo'lgan vaziyatni tasavvur qilishingiz mumkin — bu haqida butun bir mavzu mavjud, va biz buni alohida muhokama qilishimiz kerak bo'ladi. Bularning barchasida hech qanday konflikt bo'lmadi, ularni merge qilish juda oson edi — ammo keyingi videoda biz buni keyingi darajaga olib chiqib, aynan shu konfliktlar haqida gaplashamiz.