در این مقاله ما سه روش اصلی برای Branching و مدیریت branchهایی که توسط Git ساخته می‌شوند را بررسی می‌کنیم. بعد از خواندن این مقاله می‌توانید به راحتی تصمیم بگیرید که کدام روش برای چرخه توسعه شما مناسب‌تر است.
Git Flow
Git Flow یکی از روش‌های Branching که شناخته شده‌ترین روش کار در این لیست است. این روش در سال ۲۰۱۰ توسط Vincent Driessen ابداع شد که بر اساس دو branch اصلی و طول عمر بی نهایت (Infinite Lifetime) ساخته شده است:
●master: این branch شامل کدهای نهایی و عملیاتی (Production) است. تمامی کد‌هایی که توسعه داده شده است بصورت مداوم در این branch باید ادغام (merge) شود.
●develop: این branch شامل کدهای قبل از production است. وقتی کار featureها تمام می‌شود، کدها در این branch ادغام می‌شوند.
در طول چرخه توسعه ممکن است از از branchهای دیگری بجز develop و master نیز استفاده شود که آنها را پشتیبان یا supporting branches می‌نامیم که شامل موارد زیر است:
●feature: این branchها برای توسعه قابلیت‌های جدید در releaseهای آینده استفاده می‌شوند. اصولا feature branch از روی develop ساخته می‌شود و در نهایت در develop نیز ادغام می‌گردد.
●hotfix: زمانی که مثلا bug در محیط عملیات اعلام می‌شود یک branch جدید از master ایجاد می‌شود و پس از اصلاح مجدد در master و همچنین در develop ادغام می‌شوپ که به آن hotfix branch می‌گوییم.
●release: زمانی که یک feature جدید آماده عملیاتی شدن باشد ابتدا یک branch جدید از develop می‌سازیم. بنابراین تمامی تغییرات develop در این branch وجود دارد. سپس تست لازم انجام می‌شود و ممکن است bugfixهایی پس از تست هم روی این branch اعمال شود و در نهایت پس از تایید با برنچ release و develop ادغام می‌شود.
مزایا
● در هر لحظه وضعیت branchها مشخص و واضح است.
● نام‌گذاری branchهای شما از یک الگو سیستمی پیروی می‌کند که درک آن را به مراتب راحتتر می‌کند.
● زمانی ایده‌آل است که نیاز به ورژن‌های مختلفی از production داشته باشید.
معایب
● تاریخچه Git غیر قابل خواندن می‌شود.
● جدا کردن Master/develop به نظر کار اضافه‌ای است و فرایند CI/CD را سخت‌تر می‌کند.
● این روش وقتی شما فقط یک ورژن در production دارید پیشنهاد نمی‌شود.
GitHub Flow
GitHub Flow یک روش‌های بسیار سبک Branching است که در سال ۲۰۱۱ توسط GitHub معرفی شد و از شش قانون زیر پیروی می‌کند:
۱. هر چیزی که در master branch وجود دارد قابلیت استقرار (deploy) دارد.
۲. برای کار کردن بر روی چیز جدید، یک branch از master ایجاد کنید و برای آن یک اسم توصیفی در نظر بگیرید مانند new-oauth2-scopes
۳. کدهای خود را داخل branch جدید بصورت مداوم commit کنید.
۴. زمانی که کار شما آماده merge شدن است یک pull request باز کنید.
۵. بعد از اینکه شخص دیگری این feature ها را مشاهده کرد، شما می‌توانید آن را در master ادغام نمایید.
۶. وقتی تغییرات در master ادغام شد بهتر است بلافاصله تغییرات را deploy کنید.
مزایا
● مناسب و سازگار با Continuous Delivery و Continuous Integration است.
● یک جایگزین ساده برای Git Flow است.
● برای وقتی که شما یک ورژن برای production خود دارید ایده‌آل است.
معایب
● کدهای production به راحتی می‌توانند unstable باشد.
● وقتی نیاز به release plan باشد کافی نیستند.
● هیچ دغدغه‌ای را درباره deploy, environment, release و issue حل نمی‌کند.
● برای زمانی که شما چندین ورژن در production خود نیاز دارید پیشنهاد نمی‌شود.
GitLab Flow
این روش Branching در سال ۲۰۱۴ توسط GitLab ابداع شد. تفاوت عمده بین GitLab Flow و GitHub flow در branchهای محیطی است که در GitLab Flow وجود دارد (مانند staging و production)؛ زیرا ممکن است شرایطی وجود نداشته باشد که پس از هر بار merge بلافاصله این تغییرات deploy شود.
GitLab Flow بر اساس این ۱۱ قانون کار می‌کند:
۱. از feature branches استفاده کنید، به طور مستقیم درmaster کامیت نکنید.
۲. تمامی commitها را تست کنید و تست خود را محدود به تست کامیت‌های موجود در master نکنید.
۳. تمامی تست‌ها را در همه commitها اجرا کنید.
۴. بازبینی کد یا Code reviews خود را قبل از اینکه در master ادغام کنید انجام دهید نه بعد از آن.
۵. Deploymentها به صورت اتوماتیک است و به branch و tagها بستگی دارد.
۶. Tagها توسط کاربر تنظیم می‌شوند، نه توسط CI.
۷. Releaseها بر اساس Tagها هستند.
۸. Commitهایی که push شده‌اند هرگز rebased نمی‌شوند.
۹. همه اعضای تیم کار خود را از master شروع می‌کنند و در نهایت در master به پایان می‌رسانند.
۱۰. اگر باگی وجود داشته باشد ابتدا در master اصلاح می شود و سپس در سایر branchها.
۱۱. پیام‌های روی commitها نشانگر قصد شما از کار است.
مزایا
● مشخص می‌کند که چطور CI/CD را بسازید.
● تاریخچه git شما تمیزتر می‌شود، به هم ریختگی کمتری دارد و خواناتر است.
● برای وقتی که شما یک ورژن برای production خود دارید ایده آل است.
معایب
● پیچیده‌تر از GitHub Flow است.
● ممکن است وقتی که شما بخواهید چندین ورژن در production را کنترل کنید، مانند Git Flow پیچیده شود.
جمعبندی:
در این مقاله ما Branching و workflowهای شناخته شده را توضیح و مزایا و معایب آن را مورد بررسی قرار دادیم. این نکته مهم را در نظر بگیرید که روش‌های دیگری نیز وجود دارد که شما می‌توانید بر اساس نیاز پروژه خود از آن استفاده کنید.
منبع: https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf
دیدگاهتان را بنویسید