Chalkashmasdan jamoaviy ish: Git-da tarmoqlanish strategiyalarini tushunish

Kirish

Git dasturiy ta'minotni yaratishda versiyalarni boshqarish uchun de-fakto sanoat standartiga aylandi. Git nima ekanligini va qanday boshlashni bilish uchun avval bu haqda mening maqolamni o'qing. Siz uni o'qidingizmi? Ajoyib, davom etaylik! Xohlaysizmi yoki yo'qmi, Linus Tovalds yaratgan asbob iste'foga chiqmaydi. Shuning uchun, git-da taqsimlangan jamoalar qanday ishlashi va buning uchun qanday tarmoqlanish strategiyasini tanlash kerakligi haqida gapirish mantiqan. Va bu umuman behuda savol emas. Ko'pincha, bir-biri bilan hamkorlik qilmagan ishlab chiquvchilarning yangi jamoasi yig'ilgan vaziyatda, tarmoqlanish strategiyasi qaror qabul qilish kerak bo'lgan birinchi narsalardan biridir. Va bitta strategiya boshqasidan yaxshiroq ekanligini isbotlash uchun og'zidan ko'pik chiqadigan odamlar bo'ladi. Shuning uchun men sizga ularning umumiyligi haqida ma'lumot bermoqchiman.

Tarmoqlanish strategiyalari kerakmi?

Ammo ular kerak va ular hali ham kerak. Chunki agar siz jamoada biror narsaga rozi bo'lmasangiz, hamma o'zi xohlaganini qiladi:

• o'zi xohlagan filialda ishlash;
• u xohlagan boshqa filiallarga birlashish;
• ba'zi filiallarni o'chirish;
• yangilarini yaratish;
• va hokazo - jamoa a'zolarining har biri nazoratsiz oqimda.

Shunday qilib, quyida uchta strategiya mavjud. Bor!

GitHub Flow strategiyasi

GitHub-da qanchalik g'alati bo'lmasin, tarmoqlanish strategiyasi afzalroqdir :) Unga rioya qilish kerak bo'lgan qoidalar to'plami biriktirilgan:

1. Asosiy filialdagi kod buzilmagan bo'lishi va istalgan vaqtda foydalanishga tayyor bo'lishi kerak (ya'ni, siz loyihani yaratish va uni serverda joylashtirishga xalaqit beradigan kodni qo'yishingiz mumkin emas).
2. Yangi funksionallik ustida ishlashni rejalashtirganingizda, asosiy filialga asoslangan yangi filial (xususiyat shoxobchasi) yaratishingiz va unga mazmunli nom berishingiz kerak. Kodingizni mahalliy sifatida kiriting va o'zgartirishlaringizni muntazam ravishda masofaviy ombordagi bir xil filialga yuboring.
3. Ish tayyorligi va asosiy bo'limga birlashtirilishi mumkinligi aniq sezilganda (yoki ishonchingiz komil bo'lmasa, lekin fikr-mulohaza olmoqchi bo'lsangiz) Pull-Requestni oching (pull-so'rov nima ekanligini bu yerda o'qishingiz mumkin). bajarilgan ish).
4. Pull so'rovidagi yangi xususiyat tasdiqlangandan so'ng, uni asosiy filialga birlashtirish mumkin.
5. O'zgarishlar asosiy filialga birlashtirilganda, ular darhol serverga joylashtirilishi kerak.

GitHub Flow ma'lumotlariga ko'ra, yangi narsa ustida ishlashni boshlashdan oldin, u tuzatish yoki yangi xususiyat bo'lsin, master asosida yangi filial yaratish va unga mos nom berish kerak bo'ladi. Keyinchalik, amalga oshirish bo'yicha ish boshlanadi. Siz doimiy ravishda bir xil nomdagi uzoq serverga majburiyatlarni yuborishingiz kerak. Har bir narsa tayyor ekanligini tushunganingizda, asosiy filialda tortish so'rovini yaratishingiz kerak. Keyin kamida bitta yoki undan ham yaxshisi, ikki kishi ushbu kodni ko'rib, "Tasdiqlash" tugmasini bosing. Odatda, loyihaning jamoasi rahbari va boshqa birov unga qarashlari kerak, keyin siz tortishish so'rovini bajarishingiz mumkin. GitHub Flow, shuningdek , loyihada uzluksiz yetkazib berish (CD) ni boshqarish bilan ham mashhur . Chunki asosiy filialga o'zgartirishlar kiritilganda, ular darhol serverga joylashtirilishi kerak.

GitFlow strategiyasi

Oldingi strategiya (GitHub Flow) aslida unchalik murakkab emas edi. Ikki xil shoxchalar mavjud: asosiy va xususiyatli shoxlar. Ammo GitFlow jiddiyroq. Hech bo'lmaganda yuqoridagi rasmdan buni tushunishingiz mumkin) Xo'sh, bu strategiya qanday ishlaydi? Umuman olganda, GitFlow ikkita doimiy filial va bir necha turdagi vaqtinchalik filiallardan iborat (GitHub Flow kontekstida asosiy filial doimiy, boshqalari esa vaqtinchalik). Doimiy filiallar:

• usta: hech kim bu shoxga tegmasligi yoki u erga hech narsa surmasligi kerak. Ushbu strategiyada master ishlab chiqarishda (ya'ni haqiqiy serverda) ishlatiladigan eng so'nggi barqaror versiyani ko'rsatadi;
• taraqqiyot - rivojlanish sohasi. Bu beqaror bo'lishi mumkin.

Rivojlanish uchta yordamchi vaqtinchalik filiallar yordamida amalga oshiriladi :

1. Xususiyat tarmoqlari - yangi funksiyalarni ishlab chiqish uchun.
2. Chiqarish filiallari - loyihaning yangi versiyasini chiqarishga tayyorgarlik ko'rish.
3. Tuzatish filiallari haqiqiy serverda haqiqiy foydalanuvchilar tomonidan topilgan nuqsonni tezda hal qilishdir.

Xususiyatlar filiallari

Xususiyat tarmoqlari ishlab chiquvchilar tomonidan yangi funksiyalar uchun yaratilgan. Ular har doim rivojlanish sohasi asosida yaratilishi kerak. Yangi funksionallik ustida ishlashni tugatgandan so'ng, siz rivojlanish bo'limida tortish so'rovini yaratishingiz kerak. Katta jamoalarda bir vaqtning o'zida bir nechta xususiyat bo'limi bo'lishi mumkinligi aniq. Yana bir bor GitFlow strategiyasi tavsifining boshidagi rasmga e'tibor bering.

Filiallarni bo'shating

Rivojlanish bo'limida kerakli miqdordagi yangi xususiyatlar tayyorlangach, siz mahsulotning yangi versiyasini chiqarishga tayyorgarlik ko'rishingiz mumkin. Bunda bizga reliz bo'limi yordam beradi. rivojlanish sohasi asosida yaratilgan. Chiqarish filiali bilan ishlashda siz barcha kamchiliklarni topishingiz va tuzatishingiz kerak. Chiqarish tarmog'ini barqarorlashtirish uchun zarur bo'lgan har qanday yangi o'zgarishlar ham ishlab chiqishda birlashtirilishi kerak. Bu filialni barqarorlashtirish va rivojlantirish maqsadida amalga oshiriladi. Sinovchilar filialning yangi versiya uchun etarlicha barqaror ekanligini aytishganda, u asosiy filialga birlashtiriladi. Keyinchalik, ushbu majburiyat bo'yicha teg yaratiladi (teg: bu haqda batafsil ma'lumotni bu erda o'qishingiz mumkin ), unga versiya raqami beriladi. Misol tariqasida strategiyaning boshidagi rasmga qarashingiz mumkin. Shunday qilib, u erda Tag 1.0 - bu loyihaning 1.0 versiyasini ko'rsatadigan yorliq. Va oxirgi narsa - filialni tuzatish.

Tuzatish filiallari

Tuzatish bo'limlari, shuningdek, master-da yangi versiyani chiqarish uchun mo'ljallangan. Yagona farq shundaki, bu reliz rejalashtirilgan emas. Kamchiliklar paydo bo'ladigan va ishlab chiqarishda allaqachon aniqlangan holatlar mavjud. Masalan, iOS: ular yangi versiyani chiqarishi bilanoq, siz chiqarilgandan so'ng aniqlangan nuqsonlar uchun tuzatishlar bilan bir qator yangilanishlarni olasiz. Shu munosabat bilan ushbu kamchilikni tezda bartaraf etish va yangi versiyani chiqarish kerak. Bizning rasmimizda bu 1.0.1 versiyasiga mos keladi. G'oya shundan iboratki, siz haqiqiy serverdagi nuqsonni tuzatishingiz kerak bo'lgan paytlarda yangi funksionallik ustida ishlash to'xtamasligi mumkin (biz aytganimizdek, "ishlab chiqarishda": yana inglizcha "produktsiya" so'zining nusxasi). Tuzatish bo'limi asosiy filialdan yaratilishi kerak, chunki u ishlab chiqarishda ishlaydigan holatni ifodalaydi. Kamchilikning yechimi tayyor bo'lgach, u masterga birlashtiriladi va yangi yorliq yaratiladi. Chiqarish filialini tayyorlash kabi, tuzatish bo'limi ham o'z yechimini ishlab chiqish bo'limiga birlashtirishi kerak.

Forking ish oqimi strategiyasi

Forking Workflow strategiyasining bir qismi sifatida ishlab chiqish ikkita ombor mavjud bo'lgan tarzda amalga oshiriladi:

1. Barcha o'zgarishlar birlashtiriladigan asl ombor.
2. Vilkalar ombori (bu asl nusxaga o'zgartirish kiritmoqchi bo'lgan boshqa ishlab chiquvchiga tegishli bo'lgan asl omborning nusxasi).

Hozircha bir oz g'alati tuyuladi, to'g'rimi? Ochiq manbali rivojlanishga duch kelganlar uchun bu yondashuv allaqachon tanish. Ushbu strategiya quyidagi afzalliklarni beradi: ishlab chiqish asl nusxada birgalikda ishlab chiqish huquqini bermasdan vilkalar omborida amalga oshirilishi mumkin. Albatta, asl omborning egasi taklif qilingan o'zgarishlarni rad etish huquqiga ega. Yoki rozi bo'ling va ularni o'ldiring. Bu asl ombor egasi uchun ham, ba'zi mahsulotni yaratishda ishtirok etishni istagan ishlab chiquvchi uchun ham qulay. Masalan, siz Linux yadrosiga o'zgartirish taklif qilishingiz mumkin . Agar Linus mantiqiy deb qaror qilsa, o'zgarishlar qo'shiladi (!!!).

Forking ish jarayoniga misol

Forking Flow GitHub-da siz foydalanmoqchi bo'lgan kutubxona mavjud bo'lganda ishlatiladi. Uni to'liq ishlatishga to'sqinlik qiladigan nuqsoni bor. Aytaylik, siz muammoni yetarlicha o‘rgandingiz va yechimini bildingiz. Forking Workflow strategiyasidan foydalanib, siz ushbu muammoni asl kutubxona omborida ishlash huquqini bermasdan hal qilishingiz mumkin. Ishni boshlash uchun siz omborni tanlashingiz kerak, masalan, Spring Framework yadrosi Yuqori o'ng burchakdagi Fork tugmasini toping va uni bosing: Bu biroz vaqt oladi, shundan so'ng ushbu asl omborning nusxasi sizning qurilmangizda paydo bo'ladi. shaxsiy hisob, bu vilkalar ekanligini ko'rsatadi: Keyin siz odatdagidek ushbu ombor bilan ishlashingiz, asosiy filialga o'zgartirishlar kiritishingiz va hamma narsa tayyor bo'lgach, asl omborga Pull-Request yaratishingiz mumkin. Buning uchun "Yangi tortish so'rovi" tugmasini bosing :

Qaysi strategiyani tanlash kerak

Git - bu turli xil jarayonlar va strategiyalardan foydalangan holda ishlash imkonini beruvchi moslashuvchan va kuchli vosita. Ammo tanlov qanchalik katta bo'lsa, hozir qaysi strategiyani tanlashni hal qilish shunchalik qiyin bo'ladi. Shubhasiz, hamma uchun yagona javob yo'q. Hammasi vaziyatga bog'liq. Biroq, bunga yordam beradigan bir nechta tavsiyalar mavjud:

1. Avval eng oddiy strategiyani tanlash yaxshidir. Faqat kerak bo'lganda murakkabroq strategiyalarga o'ting.
2. Iloji boricha kamroq turdagi ishlab chiquvchilar filiallariga ega bo'lgan strategiyalarni ko'rib chiqing.
3. Turli strategiyalarning ijobiy va salbiy tomonlarini ko'rib chiqing va loyihaga muvofiq, to'g'risini tanlang.

Men sizga git-da tarmoqlanish strategiyasi haqida aytmoqchi bo'lgan narsam shu. E'tiboringiz uchun rahmat :) GitHub akkauntimga obuna bo'ling , men o'z ishimni u erda tez-tez o'z ishimda foydalanadigan turli texnologiyalar va vositalarda joylashtiraman

foydali havolalar

• GitHub oqimi: Git va GitHub-dan foydalanishning eng yaxshi usuli
• GitHub-da so'rovlarni oling yoki boshqa birovning loyihasiga qanday o'zgartirishlar kiritishim mumkin
• GitHub: Pull-Requests haqida
• Uzluksiz integratsiya, yetkazib berish va joylashtirish farqlanadi
• Git asoslari: teglar bilan ishlash
• Habr: Git uchun muvaffaqiyatli tarvaqaylab ketgan model