Git: Gitflow کامل – انجمن DEV

معرفی

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

در این مقاله بهترین ها را توضیح خواهم داد gitflow که وجود دارد و چرا هر یک از این بخش ها وجود دارد.

مفاهیم اصلی

برای کار با gitflow باید دو مفهوم اصلی را درک کنیم: شاخه ها و استراتژی های ادغام.

3 نوع شاخه وجود دارد:

• “شاخه های” اصلی
• شاخه های ویژگی
• تکلیف منشعب می شود

و 3 نوع استراتژی ادغام:

شاخه ها

شما می توانید Git را به عنوان یک درخت در نظر بگیرید، آن دارای تنه و شاخه های آن است.

آنها «کپی‌هایی» از سیستم اصلی هستند، بنابراین می‌توانید همه تغییراتی را که می‌خواهید بدون تغییر محتوای اصلی انجام دهید، بنابراین می‌توانید این تغییرات را برگردانید، شاخه‌های دیگر را اعمال کنید و کارهای جالب زیادی با آن انجام دهید.

“شاخه های” اصلی

من توصیه می کنم فقط یک شاخه اصلی در مخزن خود داشته باشید و نه یک develop و production شاخه ها. چرا؟ چون شاخه ها هستند شاخه ها! پیامدهای چیزی که می تواند (اما نباید) مسیرهای مختلف اصلی را دنبال کند، و نه چیزی برای حفظ حالت پایدار و هرگز تغییر مجدد.

من 100٪ مخالف استفاده از شاخه ها برای production یا نسخه های منتشر شده (شاخه هایی مانند v1.0.0 و موارد مشابه)، ما راه های بسیار دیگری (راه های صحیح!) برای انجام آن داریم و باید از این راه حل اجتناب کنیم.

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

همچنین می‌توانید از نسخه‌های موجود در GitHub استفاده کنید، که برای داشتن یک فایل فشرده با تمام کدتان بسیار مفید است و همچنین دارای ادغام‌ها و اتوماسیون‌های زیادی است.

بنابراین، به طور خلاصه:

• من استفاده از ONE شاخه اصلی، و به دلیل قدیمی بودن، آن را می نامم master، اما می توانید با آن تماس بگیرید main اگر ترجیح می دهید
• در این مقاله، من از نسخه های GitHub استفاده خواهم کرد، اما اگر از مخزن راه دور دیگری استفاده می کنید، می توانید آن را به عنوان تگ git درک کنید.

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

هنگامی که ما در یک محیط True Agile کار می کنیم، ویژگی هایی را برنامه ریزی کرده ایم که باید اجرا شوند، مانند قابلیتی که به کاربر اجازه می دهد یک حساب ایجاد کند، در اسکرام، آنها به این موارد “داستان های کاربر” می گویند.

در ابتدای هر چرخه (یا “sprint” اگر از Scrum استفاده می کنید)، یک شاخه جدید از شاخه اصلی با الگوی زیر ایجاد می شود:

// Pattern
feature/<ID in lowercase>/<description in lowercase>

// Example
feature/ant-1/create-account

این شاخه از شاخه اصلی ایجاد می شود و تمام تغییرات این ویژگی را گروه بندی می کند. پس از ادغام و آزمایش همه چیزهایی که ویژگی نیاز دارد، شاخه به شاخه اصلی ادغام می شود.

تکلیف منشعب می شود

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

آنها را می توان به عنوان “جیرا بلیط” یا “مسائل” درک کرد.

آنها از شاخه های FEATURE ایجاد شده و روی آنها ادغام می شوند.

سایر شاخه ها و پیشوندهای آنها

همانطور که در مباحث قبلی متوجه شدید، شاخه های ویژگی و وظیفه دارای پیشوندهای متفاوتی هستند، اما از الگوهای یکسانی پیروی می کنند.

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

# Same level as feature branches
hotfix
feature
refact

# Same level as task branches
task
fix
refact
chore
cicd

شما قبلا می دانید feature و task، اما بقیه را مطلع کنید.

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

refact: تغییر یک ویژگی که از قبل در سیستم وجود دارد، بدون اینکه بر رفتار آن تأثیر بگذارد. را refact شعبه در همان سطح a feature شاخه به منظور بازتاب بخشی بزرگی از سیستم شما، یک ویژگی اصلی، مانند ایجاد حساب کاربری و نه برای رفکت کردن یک حلقه for استفاده می شود.

fix: رفع اشکالی که جریان درست توسعه را دنبال می‌کند، قبل از ادغام آزمایش می‌شود، و با همه چیزهای دیگر این ویژگی ادغام می‌شود (ممکن است مدتی طول بکشد).

refact: refact شعبه در همان سطح a task شاخه به منظور بازتاب بخش های کوچکی از کد شما استفاده می شود که بر رفتار آن تأثیر می گذارد یا نه. این شاخه ها باید بخشی از یک ویژگی باشند و می توانند مواردی مانند api داخلی شما را برای ارسال پیام به موضوعات، بهبود عملکرد یک حلقه for و غیره تغییر دهند.

chore: به روز رسانی در یک نظر، یک اسکریپت توسعه، README، چیزهایی که روی کد تأثیر نمی گذارد.

cicd: به روز رسانی در خطوط لوله، تنظیمات برای استقرار.

استراتژی های ادغام

در اینجا من یک رزومه سریع در مورد موضوع ارائه خواهم کرد، اما می توانید در اسناد رسمی اطلاعات بیشتری کسب کنید.

چیزی که ما روی آن تمرکز خواهیم کرد این است: له کردن قبل از ادغام:

• هر کار باید هنگام ادغام با یک ویژگی دارای 1 تعهد باشد، بنابراین شما همیشه باید قبل از ادغام، تعهدات خود را از بین ببرید.
• هر ویژگی هنگام ادغام به شاخه اصلی باید 1 commit داشته باشد، بنابراین شما همیشه باید قبل از ادغام، تعهدات خود را از بین ببرید.

اگر GitHub به درستی آن را پیکربندی کنید، به طور خودکار commit های شما را حذف می کند:

اما شما همچنین می توانید این کار را با CLI انجام دهید، به اسناد مراجعه کنید.

نکات اضافی

الگوی پیام را متعهد کنید

من از یک نسخه ساده شده از Clean Arch برای پروژه های خود استفاده می کنم، از این نسخه می توانم آن را دریافت کنم لایه هایو الگویی که من برای پیام های commit استفاده می کنم این است:

// Pattern
<prefix>(<layer in lowercase>): <short description in lowercase>

// Examples
task(adapters): add foo adapter
fix(usecases): fix user creation
chore(none): add details to readme
cicd(none): change deploy method

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

تیم های کوچک

اگر در یک تیم کوچک کار می کنید، نیازی به داشتن شاخه های ویژگی نیست، می توانید مستقیماً با شاخه های وظیفه کار کنید، این باعث کاهش پیچیدگی سیستم شما می شود.

مزایای این GitFlow

یک تاریخچه تعهد خوب و تمیز

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

در تاریخچه روابط عمومی خود، می توانید تمام شاخه های ویژگی را ببینید (این تاریخچه حتی بهتر است اگر از برچسب های مناسب برای فیلتر کردن روابط عمومی خود استفاده کنید!) و همه شاخه ها و تغییرات مربوط به آنها را ببینید.

استاندارد

همه به یک شکل کار می کنند زیرا همه شما استانداردی دارید که باید رعایت کنید. تشخیص الگوها و درک روشی که همه تیم ها با git کار می کنند آسان تر است.

هنگام استفاده از بهترین gitconfig، کار با git بسیار آسان است:

# At the start of the cycle
git ckm
git cb feature/ant-1/create-account

# To start a task
git ck feature/ant-1/create-account
git pl
git cb task/ant-2/password-adapter

# When task finished
git acips task\(adapters\): add password adapter

# If you need to do any adjusts on your commit (even after the PR is created) you can run
git acaps task\(adapters\): add password adapter

# If there's comments on your PR and you need to fix them, create anoter commit
git acips fix pr comments

# Create the PR and it's done!
# To create another task, just start from "To start a task"

نتیجه

با تشکر از خواندن، من فکر می کنم که این مقاله همه چیزهایی را که برای کار با Git باید بدانید را در خود دارد. اگر نظری دارید، لطفاً آنها را در نظرات با ما در میان بگذارید! 😄