یک مدل موفق از شاخه در Git

آگاهی از چگونگی استفاده از Git مهم است, و این شامل حفظ یک نرم افزار مدیریت محیط توسعه مشترک.

اعتبارات

این ارسال نسخه پرتغالی اصلی است, به زبان انگلیسی, “یک Git موفق مدل انشعاب“, بموقع توسط نویسنده مجاز, وینسنت دریسن. با تشکر از شما مرد!

به دلایل فنی, برخی از کلمات کلیدی به عمد در انگلیسی نگه داشته شد. من سعی کردم برای اطمینان از اصالت از متن, اما من اعتراف می کنم که من مجبور به ایجاد تنظیمات برای تسهیل درک در زبان ما (PT-BR). هر گونه اصلاح و یا پیشنهاد برای بهبود در ترجمه خوش آمدید.

معرفی

این آموزش تنها نحوه استفاده از Git نیست. اگر این چیزی است که شما نیاز دارید, نشان می دهد نگاهی به Git دستی. همچنین هدف ما این است که نشان دهیم چگونه نرم افزار را نسخه بندی کنیم, در این مورد, نگاه نسخه بندی معنایی.

در اینجا پیشنهاد این است که مدیریت همکاری تیم در نسخه نرم افزار. شما می دانید زمانی که چندین برنامه نویس دارید “تکان دهنده” در کد منبع مشابه? این مهم است که برای سرعت بخشیدن به توسعه, اما می تواند سردرد بسیار زیاد تولید کند (از دست دادن و دوباره کاری) اگر هیچ کنترلی وجود ندارد. برای جلوگیری از رونویسی کار دیگری و اطمینان از توسعه مترقی و سازمان یافته, به حداقل رساندن درگیری ها و مدیریت نسخه های نرم افزار, این است که ما از Git و شاخه سپس.

شعبه مدل

در این ارسال من ارائه مدل توسعه من در برخی از پروژه های من استفاده می شود (هر دو در محل کار و خصوصی) مورد 1 سال پیش, و این بسیار موفق بوده است. آن زمان طولانی شده است از آنجایی که من می خواستم در مورد آن بنویسید, اما من یک برنامه در دسترس پیدا نشد, تا کنون. من قصد ندارم در مورد جزئیات پروژه صحبت, فقط در مورد استراتژی های شاخه و مدیریت از انتشار.

این مدل به طور انحصاری بر روی دستگاه گوارش به عنوان یک ابزار برای نسخه بندی تمام کد منبع ما. (راستی, اگر شما در Git علاقه مند هستید, شرکت ما GitPrime ، سال نو ارائه, زمان واقعی, برخی از تجزیه و تحلیل داده های شگفت انگیز برای بهینه سازی مهندسی نرم افزار)

چرا گیت?

برای بحث کامل از جوانب مثبت و منفی Git در مقایسه با سیستم های کنترل کد منبع متمرکز, نگاه a وب. فوق العاده ای وجود دارد “جنگ” اطراف آن. به عنوان یک توسعه دهنده, من ترجیح می دهم Git در مقایسه با تمام ابزارهای دیگر موجود امروز. Git بدون شک تغییر راه توسعه دهندگان فکر ساخت ادغام یا ایجاد یک شاخه. من از دنیای کلاسیک CVS/براندازی, جایی که ادغام/انشعاب این چیزی است که شما فقط یک بار در در حالی که انجام و آن را همیشه به نظر می رسد کمی ترسناک (“برحذر باشید از درگیری های ادغام, آنها شما را نیش!”).

با دستگاه گوارش این اقدامات [ادغام/انشعاب] بسیار ساده هستند و یکی از بخش های اصلی روال کار ما را نشان می دهند, باور. مثلا, در کتاب CSV/براندازی, انشعاب E ادغام برای اولین بار تنها در فصل بعد خطاب (برای کاربران پیشرفته), در حالی که در هر کتاب در مورد گیت, این است که در فصل دیده می شود 3 (اساسی).

به عنوان یک نتیجه از سادگی و تکراری طبیعت, انشعاب E ادغام آیا دیگر چیزی به ترس از. در واقع, ابزارهای کنترل نسخه باید کمک کنندادغام و ایجاد شاخه بیش از هر چیز دیگری.

نه بیشتر صحبت کردن, بیایید به مدل توسعه برویم. مدل من در اینجا ارائه خواهد شد اساسا چیزی بیش از مجموعه ای از روش های که هر یک از اعضای تیم باید به دنبال آمد تا با یک فرآیند توسعه نرم افزار مدیریت.

غیر متمرکز, اما متمرکز

پیکربندی مخزن استفاده می کنیم و با این نسخهها کار بزرگ انشعاب از یک مخزن مرکزی تشکیل شده است. توجه داشته باشید که این مخزن تنها “در نظر گرفته به عنوان” مرکزی (از آنجا که Git DVCS است [سیستم های کنترل نسخه توزیع شده], به عبارت دیگر, هیچ چیز مانند یک مخزن مرکزی در سطح فنی وجود ندارد). ما این مخزن را به عنوان مرجع منشاء, از آنجا که این نام برای همه کاربران Git آشنا است.

هر توسعه دهنده می کند کشد E هل برای این منشاء. اما فراتر از رابطه فشار جلو برای متمرکز [منشاء], هر توسعه دهنده همچنین می تواند انتخاب کند تا [جلو] تغییرات دیگر جفت ها برای تشکیل زیرتیم ها. مثلا, این می تواند برای کار در کنار دو یا چند توسعه دهندگان در یک قابلیت جدید بزرگ مفید باشد, قبلا ارسال [هل دادن] کار در حال پیشرفت برای منشاء. در شکل بالا, هستند subteams آلیس و باب وجود دارد, آلیس و دیوید, و کلیر و دیوید.

فنی, این به این معنی هیچ چیز بیشتر که آلیس یک Git از راه دور به نام باب تعریف, اشاره به مخزن باب, و بالعکس.

شاخه های اصلی

در پس زمینه, این مدل توسعه کاملا الهام گرفته از مدل های موجود در خارج وجود دارد. مخزن مرکزی دارای دو شاخه است [شاخه] بالا با یک زندگی بی نهایت:

  • استاد
  • توسعه

O استاد شعبه به منشاء باید به هر کاربر گیت آشنا باشد. موازی به استاد شعبه, دیگری وجود دارد شاخه نام توسعه.

نظر منبع/کارشناسی ارشد به عنوان شاخه اصلی که در آن کد منبع سر همیشه منعکس کننده حالت تولید آماده [آماده تولید].

نظر منبع/توسعه به عنوان که شاخه که در آن کد منبع از سر همیشه منعکس کننده حالت با آخرین تغییرات توسعه در نسخه بعدی تحویل داده می شود. برخی از آن تماس بگیرید “شاخه ادغام”. این جایی است که ساختمان های شیطانی ترین اتفاق می افتد.

هنگامی که کد منبع در توسعه شعب به یک نقطه پایدار می رسد و آماده است تا منتشر شود [منتشر شد], همه تغییرات باید ادغام شوند [ادغام] بازگشت به استاد شعبه و سپس با یک شماره نسخه با برچسب [رهایی]. چگونه این است که در جزئیات انجام می شود, بعدا بحث خواهد شد.

بنابر این, هر بار که تغییرات گنجانیده شده [ادغام] بازگشت به استاد, یک نسخه جدید تولید می شود [منتشر شد], با تعریف. ما سعی می شود کاملا سخت در این, سپس, تئوری, ما حتی می تواند یک اسکریپت استفاده قلاب git به صورت خودکار ایجاد و ارسال درخواست ما به سرورهای تولید هر زمان که یک متعهد در استاد.

شاخه های کمکی

بعد به شاخه اصلی, استاد E توسعه, مدل توسعه ما با استفاده از انواع شاخه پشتیبانی برای کمک به توسعه به طور همزمان در میان اعضای تیم, چه چیز 1) ردیابی ویژگی های جدید را آسان می کند [ویژگی], 2) آماده برای تحویل یک نسخه جدید [رهایی] E 3) به سرعت برطرف کردن خرابی های تولید کمک می کند [Hotfix]. بر خلاف شاخه اصلی, این شاخه طول عمر کوتاه دارد, از آنجا که در نهایت آنها حذف خواهد شد.

انواع مختلف شاخه [کمکی] که ما می توانیم از, هستند:

  • شاخه های ویژگی
  • شعب انتشار
  • شاخه های Hotfix

هر یک از این شاخه دارای یک هدف خاص است و با قوانین سختگیرانه محدود شده است, بطوریکه, شاخه ممکن است به افزایش شاخه و این شاخه باید ادغام شوند [ادغام] به اهداف خود. ما هر یک از آنها را می بینیم [شاخه] در یک لحظه.

از منظر فنی, این شاخه در نظر گرفته نشده “ویژه”. هر نوع از شاخه توسط نحوه استفاده از آنها طبقه بندی می شود. در نهایت, فقط ساده شاخه از گیت قدیمی خوب.

شاخه های ویژگی

[ویژگی ها = ویژگی ها/ویژگی ها]

– شما می توانید شعبه خارج [شاخه] از:
توسعه
– باید ادغام شود [ادغام] دوباره به:
توسعه
– کنوانسیون انتصاب شاخه:
چیزی, جز استاد, توسعه, آزاد-*, یا hotfix-*

این شاخه های ویژگی (یا گاهی اوقات به نام شاخه های موضوعی) برای توسعه ویژگی ها/قابلیت های جدید برای نسخه نزدیک یا آینده استفاده می شود. هنگام شروع توسعه یک ویژگی, نسخه هدف که در آن این ویژگی تعبیه خواهد شد ممکن است در آن نقطه ناشناخته باشد.

جوهر یک شاخه های ویژگی این است که آن وجود دارد در حالی که ویژگی در حال توسعه است, اما در نهایت از آن خواهد شد گنجانیده [ادغام] بازگشت به توسعه (به قطعا اضافه کردن جدید ویژگی به بعد رهایی) یا دور انداخته (در صورت آزمایش ناموفق).

شاخه های ویژگی به طور معمول تنها در مخزن وجود دارد توسعه, نه در منشاء.

ایجاد شاخه های ویژگی

$ دستگاه گوارش پرداخت -B myfeature توسعه
# Switched to a new branch "myfeature"

جاسازی یک ویژگی به پایان رسید در توسعه

امکانات ، سال نو تکمیل شده می تواند ادغام شود[ادغام] با این توسعه شعب قطعا آنها را به بعد اضافه کنید رهایی.

$ پرداخت دستگاه گوارش توسعه
# تغییر به شاخه ' توسعه '
$ دستگاه گوارش ادغام --در-myfeature ff
# به روز رسانی ea1b82a.. 05e9557
# (خلاصه تغییرات)
# $ واحد گیت-d myfeature
# حذف شعبه myfeature (05e9557 بود).
$ git منبع فشار توسعه

پرچم –بدون ff باعث ترکیب [ادغام] همیشه جدید ایجاد کنید متعهد, حتی اگر ادغام می تواند با انجام سریع به جلو [Ff]. این مانع از اطلاعات در مورد تاریخ وجود یک شاخه ویژگی, گروه بندی تمام مرتکب که به آن اضافه شده ویژگی. مقایسه:

در مورد دوم [از شکل بالا], این غیر ممکن است از تاریخ git که از مرتکب در یک ویژگی; شما می توانید به صورت دستی تمام پیام های ورود به سیستم را بخوانید. معکوس یک ویژگی کل (به عبارت دیگر, یک گروه از مرتکب), این یک سردرد واقعی در آخرین وضعیت است, در حالی که این به راحتی انجام می شود اگر پرچم –بدون ff استفاده شده است.

سیم کارت, این کار چند شئ دیگر ایجاد خواهد کرد مرتکب (خالی), اما سود بسیار بالاتر از هزینه است.

شعب انتشار

[انتشار = انتشار/تحویل/نسخه]

– شما می توانید شعبه خارج [شاخه] از:
توسعه
– باید ادغام شود [ادغام] دوباره به:
توسعه E استاد
– کنوانسیون انتصاب شاخه:
آزاد-*

این شعب منتشر شده کمک در تهیه یک نسخه جدید تولید [انتشار تولید]. آنها به شما اجازه قرار دادن میگذرد در آخرین لحظه من. به علاوه, آنها اجازه می دهد برای اصلاحات جزئی از اشکالات و تعریف از متا داده ها مجامع رهایی (شماره نسخه, ساخت خرما, و غیره). با انجام تمام این کار در یک شعبه انتشار, o توسعه شاخه پاک می شود برای دریافت ویژگی از بزرگ بعدی رهایی [نسخه].

لحظه ای کلیدی برای ایجاد یک جدید شعبه انتشار انشعاب از توسعه است که زمانی که توسعه است در حال حاضر (تقریبا) منعکس کننده وضعیت مورد نظر جدید رهایی [نسخه]. همه ویژگی نامزدها برای رهایی ساخته می شود باید گنجانیده شده [ادغام] the توسعه در این مرحله. از طرف دیگر ویژگی با هدف در انتشار آینده باید انتظار آینده رهایی [نسخه].

این درست در ابتدای یک شعبه انتشار که بعد رهایی دریافت شماره نسخه – نه قبل از. تا آن لحظه, o توسعه شاخه منعکس تغییرات به “نسخه بعدی” [نسخه بعدی], اما مشخص نیست که این “نسخه بعدی” خواهد شد در نهایت 0.3 یا 1.0, تا زمانی که شعبه انتشار شروع شود. این تصمیم گرفته شده است در آغاز شعبه انتشار و توسط قوانین پروژه در نسخه بندی انجام [پیشنهاد دیدن درباره “نسخه بندی معنایی“].

ایجاد شعبه انتشار

این شعب منتشر شده ایجاد می شوند از توسعه شاخه. مثلا, بگذارید بگوییم نسخه 1.1.5 نسخه فعلی تولید است و ما باید مقدار زیادی از رهایی آینده. دولت از توسعه آماده است برای “نسخه بعدی” [نسخه بعدی] و ما تصمیم گرفتیم که این تبدیل به 1.2 (در عوض 1.1.6 یا 2.0). سپس, ما شاخه بیرون و به شعبه انتشار نامی که منعکس کننده شماره نسخه جدید است:

$ دستگاه گوارش پرداخت -B انتشار-1.2 توسعه
# Switched to a new branch "release-1.2"
$ ./ضربت-نسخه.شهرام 1.2
# پرونده ها با موفقیت تغییر کردند, نسخهٔ ضربه به 1.2.
$ git متعهد -a -محمد "Bumped version number to 1.2"
# [فایل منتشرشده-۱/۲ 74d9424] ضربه شماره نسخه به 1.2
# 1 فایل های تغییر یافته, 1 درج(+), 1 حذف(-)

پس از ایجاد یک جدید شاخه و دسترسی به آن, ما به شماره نسخه دست انداز. اینجا, bump-version.sh یک اسکریپت پوسته است که برخی از فایل های کپی کار را برای بازتاب نسخه جدید تغییر می دهد. (این می تواند, واضح, تغییر دستی – نکته این است که برخی از فایل ها را تغییر دهید.) سپس, ساخته شده است که متعهد از شماره نسخه اصلاح.

این جدید شاخه ممکن است وجود داشته باشد برای مدتی, تا زمانی که رهایی است که قطعا راه اندازی. در طول این مدت, رفع اشکال را می توان در این استفاده کرد شاخه (به جای این توسعه شاخه). علاوه بر این از جدید و بزرگ ویژگی در اینجا اکیدا ممنوع است. آنها باید ادغام شوند [ادغام] به توسعه E, پس, منتظر بزرگ بعدی رهایی.

نهایی شعبه انتشار

هنگامی که این شعبه انتشار آماده برای تبدیل شدن به یک نسخه واقعی است, برخی از اقدامات باید انجام شود. اول, o شعبه انتشار ادغام می شود استاد (از آنجا که هر متعهد در استاد یک نسخه جدید تعریف شده است, خاطر داشته باشید). سپس, این متعهد در استاد باید مشخص شود به منظور تسهیل در آینده اشاره به این تاریخ نسخه. سرانجام, تغییرات انجام شده در شعبه انتشار باید ادغام شوند [ادغام] دوباره برای توسعه, به طوری که این انتشار آینده نیز شامل این رفع اشکال.

دو مرحله اول در گیت:

$ git کارشناسی ارشد وارسی
# تغییر به شاخه کارشناسی ارشد
$ دستگاه گوارش ادغام --در-فاینال فانتزی انتشار-1.2
# ادغام ساخته شده توسط بازگشتی.
# (خلاصه تغییرات)
$ برچسب گیت -a 1.2

O رهایی در حال حاضر به اتمام و مشخص شده برای مرجع آینده.

اظهار: همچنین می توانید از پرچم های-s یا-u استفاده کنید برای امضای برچسب خود را رمزنگاری.

برای حفظ تغییرات انجام شده در شعبه انتشار, ما باید آنها را کنار هم قرار دهیم توسعه. بدون گیت:

$ پرداخت دستگاه گوارش توسعه
# تغییر به شاخه ' توسعه '
$ دستگاه گوارش ادغام --در-فاینال فانتزی انتشار-1.2
# ادغام ساخته شده توسط بازگشتی.
# (خلاصه تغییرات)

این مرحله می تواند منجر به تداخل ادغام شود (احتمالا برو, هنگامی که شماره نسخه را تغییر دهید). اگر چنین, تعمیر و انجام این متعهد.

اکنون, که ما واقعا شکست, o شعبه انتشار می تواند حذف شود, از آنجا که ما دیگر به آن نیاز نداریم:

$ واحد گیت -d انتشار-1.2
# شعبه حذف شده آزاد-۱/۲ (ff452fe شد).

شاخه های Hotfix

– شما می توانید شعبه خارج [شاخه] از:
استاد
– باید ادغام شود [ادغام] دوباره به:
توسعه E استاد
– کنوانسیون انتصاب شاخه:
hotfix-*

این شاخه های Hotfix بسیار شبیه به شعب انتشار, از آنجا که آنها نیز در نظر گرفته شده برای تهیه یک نسخه تولید جدید, اگر چه بدون برنامه ریزی. آنها از نیاز به عمل بلافاصله پس از یک دولت ناخواسته از نسخه تولید بوجود می آیند [در استفاده]. هنگامی که یک خطای بحرانی در یک نسخه تولید رخ می دهد, باید فورا حل شود, سپس یک شعبه hotfix می توان از برچسب مشتق شده است که نشانه های موجود در نسخه تولید شاخه اصلی.

جوهر این است که کار اعضای تیم (در توسعه شاخه) می توانید ادامه دهید, در حالی که شخص دیگری در حال آماده سازی سریع رفع شکست تولید.

ایجاد شاخه hotfix

این شاخه های hotfix ایجاد می شوند از شاخه اصلی. مثلا, با فرض این که نسخه 1.2 آیا نسخه فعلی از انتشار تولید در حال اجرا و ارائه مشکلات به دلیل یک خطای جدی. تغییر در توسعه ترک هنوز هم ناپایدار است. ما پس از آن می توانید شعبه شعبه hotfix و شروع به حل مشکل:

$ دستگاه گوارش پرداخت -b hotfix-1.2.1 استاد
# Switched to a new branch "hotfix-1.2.1"
$ ./ضربت-نسخه.شهرام 1.2.1
# پرونده ها با موفقیت تغییر کردند, نسخهٔ ضربه به 1.2.1.
$ git متعهد -a -محمد "Bumped version number to 1.2.1"
# [hotfix-1.2.1 41e61bb] ضربه شماره نسخه به 1.2.1
# 1 فایل های تغییر یافته, 1 درج(+), 1 حذف(-)

فراموش نکنید که شماره نسخه را بعد از شاخه تغییر دهید!

سپس, تصحیح خطا و ایجاد متعهد اصلاح در یک یا چند متعهد جداگانه.

$ git متعهد -محمد "Fixed severe production problem"
# [hotfix-1.2.1 abbe5d6] مشکل تولید شدید ثابت
# 5 فایل های تغییر یافته, 32 درج(+), 17 حذف(-)

تکمیل شاخه hotfix

هنگامی که به پایان رسید, o Bugfix نیاز به دوباره به ادغام استاد, اما همچنین نیاز به گنجانیده دوباره به توسعه, به منظور اطمینان حاصل شود که Bugfix نیز در نسخه بعدی گنجانده شده است. این کاملا شبیه به راه است شعب انتشار به پایان رسید.

اول, روز کنید استاد و برچسب رهایی [علامت گذاری در تابستان]:

$ git کارشناسی ارشد وارسی
# تغییر به شاخه کارشناسی ارشد
$ دستگاه گوارش ادغام --در-hotfix ff-1.2.1
# ادغام ساخته شده توسط بازگشتی.
# (خلاصه تغییرات)
$ برچسب گیت -a 1.2.1

اظهار: همچنین می توانید از پرچم های-s یا-u استفاده کنید برای امضای برچسب خود را رمزنگاری.

سپس, شامل این Bugfix در توسعه همچنین:

$ پرداخت دستگاه گوارش توسعه
# تغییر به شاخه ' توسعه '
$ دستگاه گوارش ادغام --در-hotfix ff-1.2.1
# ادغام ساخته شده توسط بازگشتی.
# (خلاصه تغییرات)

تنها استثنا برای این قانون در اینجا این است که, هنگامی که یک شعبه انتشار در حال انجام, تغییرات از Hotfix باید برای این ادغام شود شعبه انتشار, جای توسعه. ادغام کنید Bugfix در شعبه انتشار باعث می شود که Bugfix ادغام شده به توسعه همچنین, هنگامی که این شعبه انتشار تکمیل شده است. (اگر کار در توسعه بلافاصله نیاز به این Bugfix و نمی تواند صبر کنید تا شعبه انتشار تکمیل شده است, شما می توانید با خیال راحت ادغام Bugfix برای deveolp همچنین.)

سرانجام, حذف کنید شاخه موقت:

$ واحد گیت -hotfix d-1.2.1
# شاخه حذف شده hotfix-1.2.1 (abbe5d6 شد).

خلاصه

اگر چه هیچ چیز واقعا فوق العاده ای در این مدل انشعاب وجود دارد, رقم در ابتدای ارسال می تواند در پروژه های ما بسیار مفید باشد. این نشان می دهد که یک مدل ذهنی آسان برای درک و اجازه می دهد تا اعضای تیم به منظور توسعه یک درک مشترک از انشعاب E آزاد.

نسخه پی دی اف با کیفیت بالا از این رقم است که در این وبلاگ از ارسال اصلی ارائه شده: http://nvie.com/posts/a-successful-git-branching-model/ [یا در لینک دانلود زیر]. برو جلو و محل آن را بر روی دیوار برای دریافت مرجع سریع در هر زمان.

تعداد دسترسی ها: 8375

مروری بر “یک مدل موفق از شاخه در Git

  1. تولد Deivson گفت:

    بعد از ظهر خوب, من می دانم که دستگاه گوارش در ابتدا توسط سیستم لینوکس اما هنگامی که صحبت کردن در قابلیت حمل توسعه داده شد, من تعجب می کنم اگر دستگاه گوارش قابل اجرا بر روی ویندوز و POSIX MSIS??

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخشهای موردنیاز علامتگذاری شدهاند با *