منبع اصلی نوشتار زیر در این لینک قرار دارد

مدل انشعاب گیری موفق در گیت

در این مقاله مدلی را برای استفاده در تمامی پروژه های خصوصی و شرکتی پیشنهاد شده که با موفقیت جلو رفت. این مدل با گیت پیاده‌سازی و پیشنهاد شده.

001

جدا اما مرکزی

در این مدل یک مخزن درست اصلی ایجاد می‌شود. قابل اشاره است که این مخزن تنها مخزنی است که به عنوان مخزن مرکزی برنامه لحاظ گردیده. ما این مخزن را به عنوان origin می‌شناسیم، چرا که این نام برای تمامی کاربران آشنا با گیت شناخته شده است.

002هر برنامه نویس عمل pull و push را به origin انجام می‌دهد. اما در پس پرده ارتباط این pull و push مرکزی، هر توسعه‌ دهنده ممکن است برخی تغییرات را از دیگر منابع به زیر گروه pull کند. برای مثال این روش ممکن است برای کار کردن با بیشتر از دو توسعه‌دهنده روی یک ویژگی پیچیده یا بزرگ برنامه، قبل از push کردن تغییرات نابهنگام روی origin اصلی، مفید باشد. در تصویر فوق، زیر تیم‌هایی از آلیس و باب، آلیس و دیوید کلیر و دیوید به چشم می‌خورند.

انشعاب اصلی

در هسته، مدل توسعه الهام گرفته شده از مدل مثالی بالا است. مخزن مرکزی حاوی دو انشعاب اصلی با چرخه حیات بینهایت به نام‌های زیر می‌باشد:

  • master
  • develop

انشعاب master در origin برای هر کاربری گیتی آشنا می‌باشد. در راستای با انشعاب master، یک انشعاب دیگر به نام develop نیز وجود دارد. ما origin/master را به عنوان انشعاب اصلی می‌شناسیم که منبع کد HEAD همیشه به عنوان حالت آماده تجاری و نهایی دیده می‌شود.

ما origin/develop را به عنوان انشعاب اصلی منبع کد HEAD که همیشه در حالت آخرین تغییرات تیم توسعه برای نسخه بعدی می‌باشد، است. همچنین برخی نیز ممکن است این انشعاب را به نام ”integration branch ” بشناسند. این انشعاب جایی است که خروجی های غیر اصلی و غیر نهایی برنامه روی آن قرار می گیرند.

003

زمانی که کدهای برنامه روی انشعاب develop به یک نقطه پایدار رسیده و آماده انتشار نسخه بعدی باشد، تمامی تغییرات موجود روی آن باید به انشعاب master ادغام شده و سپس با شماره نسخه جدید تگ گزاری شود. از این روی هر زمان که تغییرات به master ادغام شوند، این یک نسخه جدید تجاری می‌باشد. ما درباره این سخت‌گیر هستیم،‌بنابراین به طور تئوریک، می‌توان از اسکریپت خودکار ایجاد گیت hook استفاده کرده و برنامه نهایی را هر زمان که یک کامیت روی master ایجاد می‌شود، روی سرور تحاری منتشر شود.

انشعابات پشتیبان

مورد بعدی درباره انشعابات master و develop، مدل توسعه از تعدادی انشعاب پشتیبان دیگر به منظور کمک کردن در توسعه برنامه بین اعضای مختلف تیم، که هرکدام ویژگی‌ای از برنامه را دنبال می‌کنند که باید برای نسخه‌های تجاری آماده شوند و به رفع سریع مشکلات روی سرور نهایی کمک می کند، نیز بهره می‌گیرد. برخلاف انشعاب اصلی، این انشعابات همیشه سرانجام بعد از اتمام کارشان حذف می‌شوند و دارای چرخه حیات محدود هستند. برخی از این انشعابات به صورت زیر می‌باشند:

  • انشعاب Feature
  • انشعابRelease
  • انشعابHotfix

هر کدام از این انشعابات هدف و دیدگاه خاص خود را دارند که براساس آن‌ها قوانینی مشخص از قبیل تعیین کدام انشعابات باید انشعابات بعدی را تولید کنند و کدام انشعابات باید با اکدام انشعابات ادغام شوند، را شامل می‌شوند. این انشعابات براساس نوع استفاده آن‌ها دسته بندی می‌شوند.

004

 انشعابات ویژگیها

ممکن است یک انشعاب از develop باشد.

باید به انشعاب develop ادغام شود.

قوانین نامگزاری انشعابات می‌تواند هر چیزی به غیر از master, develop, releas-*, hotfix-* باشد.

انشعابات ویژگی ها (که در برخی موارد به نام انشعابات سرفصل نامیده می‌شوند) برای توسعه ویژگی‌های جدید برای قرار گرفتن یا حذف از روی نسخه بعدی استفاده می‌شوند. انشعابات ویژگی‌ها نوعا روی انشعاب وجود داشته ولی روی انشعاب origin وجود ندارد.

ایجاد یک انشعاب ویژگی

به هنگام شروع برای یک ویژگی جدید، نحوه ایجاد انشعاب جدید از develop به صورت زیر می باشد:

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

نحوه برگشت یک ویژگی تمام شده به develop

ویژگی جدید ایجاد شده زمانی که به پایان برسد باید به انشعاب ادغام شود تا در نسخه بعد منتشر شود:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

سویچ no-off—موجب می‌شود تا عمل ادغام همیشه یک کامیت جدید ثبت کند حتی اگر آن ادغام خیلی صولانی نبوده و مجدد تصمیم به باز گشت آن گرفته شود. مزیت این کار در این است که جلوی از دست رفتن سابقه اعمال صورت گرفته روی انشعاب زده شده برای ویژگی جدید را می‌گیرد. خودتان مقایسه کنید:

005در انشعاب سمت راست تصویر قابل مشاهده است که سابقه و تاریخچه کاری روی ویژگی جدید قابل پیگیری و مشخص نمی‌باشد، در این صورت شما باید تمامی پیام‌های لاگ شده را بررسی کنید. بازگشت به عقب کل یک ویژگی (گروهی از کامیت‌ها) یک دردسر واقعی است، جایی که این کار به راحتی توسط سویچ no-ff– امکان‌پذیر است. این سویچ باعث می‌شود تا تعداد بیشتری کامیت ثبت شوند، اما منفعت آن خیلی بیشتر از این هزینه آن است.

انشعابات نسخه قابل انتشار

احتمالاً از انشعاب develop قابل انشعاب گرفتن باشد.

حتماً باید به انشعابات develop و master ادغام شوند.

قوانین نامگزاری انشعابات به صورت releas-* می‌باشد.

انشعابات نسخه قابل انتشار برای آماده سازی برنامه جهت انتشار نسخه آپدیت نهایی جدید است. این انشعابات امکان رفع خطاها و آماده سازی داده‌های اولیه جهت برای انتشار نسخه نهایی (شماره نسخه، تاریخ ایجاد و…) را فراهم می کند. با انجام تمام این امور روی انشعاب انتشار نهایی، انشعاب develop جهت آماده بودن برای دریافت ویژگی‌های جدید برای آپدیت و نسخه بزرگ بعدی، خالی می‌شود.

زمانی که قصد ادغام انشعاب develop را جهت انتشار نسخه نهایی را داریم باید تمامی ویژگی‌هایی که برای انتشار در این نسخه در ظر گرفته شده‌اند، باید به انشعاب develop ادغام شوند.

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

این انشعاب از انشعاب develop ایجاد می‌شود. برای مثال، نسخه فعلی ۱.۱.۵ می‌باشد و ما نسخه آپدیت جدید بزرگی را در راه داریم. وضعیت انشعاب develop آماده برای نسخه بعدی بوده و تصمیم برای انتشار نسخه شماره ۱.۲ را داریم. پس یک انشعاب جدید برای نسخه با شماره جدید ایجاد می‌کنیم:

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

بعد از ایجاد انشعاب جدید و سویچ به آن، شماره نسخه جدید را نیز اعلام می‌کنیم. برنامه bump-version.sh یک برنامه شل اسکریپت جهت ایجاد تغییرات در برخی فایل‌های موجود روی انشعاب به منظور اعلام شماره نسخه جدید است(البته این امر می‌تواند به صورت دستی انجام شود). سپس این تغییرات مشخص برای اعلام شماره نسخه جدید کامیت می‌شوند.

این انشعاب جدید برای مدتی آنجا وجود خواهد داشت، تا زمانی که نسخه اصلی قطعاً منتشر شود. در این بازه زمانی، امکان رفع برخی خطاهادر این انشعاب می‌باشد. افزودن ویژگی‌های بزرگ در این انشعاب اکیدا منع شده است. بلکه آن‌ها باید به انشعاب develop اضافه شده و منتظر انتشار نسخه اصلی بعد باشند.

اتمام یک انشعاب قابل انتشار اصلی

زمانی که وضعیت انشعاب قابل انتشار به انتشار اصلی تغییر کند، یک سری اعمال باید انجام شوند. اول، انشعاب قابل انتشار به انشعاب master ادغام شود، سپس این کامیت روی انشعاب master باید ارجاع راحت در آینده به این نسخه تگ گزاری شود، و در نهایت، تغییرات روی انشعاب قابل انتشار به انشعاب باز گردانده شود، تا نسخه بعد در آینده حاوی مشکلات رفع شده نهایی نیز باشد. این اعمال به ترتیب زیر است:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

انتشار نسخه نهایی انجام شده و برای ارجاعات آینده تگ گزاری شده است. جهت حفظ آخرین تغییرات انجام شده روی انشعاب ایجاد شده برای نسخه قابل انتشار، لازم است تا آن انشعاب را با انشعاب develop به صورت زیر ادغام نماییم:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

در این گام امکان تداخل در فایل‌ها بعد از ادغام وجود دارد، در این صورت پس از برطرف نمودن تداخل ها کامیت نمایید. اکنون کار تمام است پس به انشعاب ایجاد شده برای این نسخه‌ای که اخیراً منتشر شد، نیازی نمی‌باشد پس می‌توان آن را به صورت زیر حذف نمود:

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

انشعابات هاتفیکس

این انشعاب از انشعاب master گرفته می شود.

باید به انشعابات master و develop ادغام شود.

قوانین نامگزاری به صورت hotfix-* می‌باشد.

انشعابات هاتفیکس‌ها شباهت بسیار زیادی به انشعابات نسخه نهایی قابل انتشار در اینکه این انشعابات نیز آماده شده برای قرار گرفتن در نسخه بعدی می‌باشد اما از قبل پیش‌بینی نشده بودند، دارند. در این انشعابات مستقیماً با وضعیت نسخه نهایی کاربردی در ارتباط می‌باشد. زمانی که یک مشکل اصلی و خطرناک در نسخه نهایی در حال کار پیش آید که باید سریعاً رفع شود، انشعاب هاتفیکس از تگ متناظر روی انشعاب master که با نسخه نهایی نشانه گزاری شده است، ایجاد می‌شود.

مزیت ایجاد این انشعاب این است که همزمان با توسعه برنامه امکان رفع مشکلات برنامه توسط برنامه نویسان فراهم می‌آید.

006

نحوه ایجاد انشعاب هاتفیکس

انشعابات هاتفیکس از انشعاب master ایجاد می‌شوند. برای مثال اگر نسخه نهایی فعلی ۱.۲ در حال کار باشد و در این وضعیت مشکل پیش آید. هم‌اکنون امکان رفع آن مشکل روی انشعاب در حال توسعه develop نمی باشد. پس باید انشعاب دیگری برای ایجاد شود:

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

از اعلام نسخه جدید مربوط به این هاتفیکس در فایلهای روی مخزن بعد از ایجاد انشعاب فراموش نشود. سپس برای مراحل رفع مشکل کامیت های مربوطه را ثبت نمایید:

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

اتمام یک انشعاب هاتفیکس

بعد از اتمام رفع مشکل، باید انشعاب هاتفیکس مورد نظر به انشعاب master ادغام (ارجاع) شود، همزمان باید به انشعاب develop نیز به منظور جلوگیری از بروز این مشکل در نسخه آپدیت بعد ادغام (ارجاع) شود. سپس انشعاب master را با این انتشار جدید تگ گزاری می کنیم:

 

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

سپس مشابه همین عمل را نیز برای انشعاب انجام می‌دهیم:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

یک نکته قابل توجه این است که اگر انشعاب نسخه قابل انتشار هم‌اکنون وجود دارد، پس از اتمام رفع مشکل، انشعاب هاتفیکس باید به جای ادغام با انشعاب develop به آن انشعاب ادغام شود. همانطور که قبلاً بیان شد، نهایتاً انشعاب نسخه نهایی قابل انتشار به انشعاب develop ارجاع خواهد شد. در پایان انشعاب موقت هاتفیکس باید حذف شود:

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6)

منبع: nvie.com

The post مدل انشعاب گیری موفق در گیت appeared first on دست نوشته های یک تازه کار.



برچسب ها : , , ,

به سیاره لینوکس امتیاز دهید

به اين صفحه امتياز دهيد