گیت فلو چیست؟ با گیت آسون تر کار کن!

جامعه هدف این مقاله:

هر برنامه نویس با هر زبانی که دوست داره یکم با گیت راحت تر کار کنه و باکلاس تر. برای حرفه ای ها هم اگه ندونن چیه کلا عیبه باید بدونن.

خب خیلی خوش اومدی یه مقاله خیلی جامع نوشتم راجب git-flow و میخوام از خیلی از دستورات بد قلق گیت خلاصت کنم، یکم بروز تر کد بزنی مثل یک حرفه ای کد هاتو مرج کنی و پوش کنی، داخل پرانتز بگم تجربیات خودمم نوشتم، پس بزن بریم ?.

شاید تا به حال زیاد درگیر merge - branch و این چیزا شده باشین و خیلی به مشکل خورده باشید، خب ماهم توی شرکتمون به این مشکل خوردیم و دنبال راهکار بودیم چطوری میشه مقداری از این مشکلات رو کاهش داد، رسیدیم به ابزار دوست داشتی به نام git flow تقریبا 90 درصد مشکلات مارو حل کرد خیلیم باکلاسه، من سعی کردم که مفید ترین دستوراتش رو بنویسم، حالا براتون توضیح میدم.

بزارین همین اول خلاصتون کنم هرکجای پروژتون هستید شروعش نکردید یا آخراش هستید بازم این مقاله بدردتون میخوره، فرض ما این هست که یک پروژه رو درحد new project جلو رفتیم و سلوشن پروژه کویر نیست.

بخش اول نحوه کار Git Flow

کسی که با گیت فلو کار کرده عکس زیر رو بهش نشون بدی چشم بسته میگه این عکس مربوط به گیت فلو هست بیاین باهم نگاهش کنیم ببینیم مگه چجوریه عکسش:

یکم که بهش نگاه میکنید میبینید که شماهم توی پروژتون چیزایی مثل توسعه جدید (Feature) یا نسخه های نهایی (Release) دارید این وسط یک چیزایی هم مثل Master و Develop وجود داره که مربوط به گیت هستند؛ اما این ها ربطشون چیه؟ درواقع ما میایم هر نسخه ای که تحویل مشتری میدیم یا مشتری از ما چیزی میخواد بهش اضافه میکنیم رو درون برنچ هایی از گیت نگهداری میکنیم دیگه نمیترسیم اگر مشتری گفت این آپدیت خراب شده برگردونید به حالت قبلی دست و پای ما بلرزه راحت براش انجام میدیم؛ یا مثلا میتونیم ورژن بزاریم و بگیم تحویل در ابتدای تیر ورژن v0.1 بوده اینطوری ردیابی تغییرات خیلی ساده میشه.

بخش دوم نصب Git Flow

macOS

Homebrew

brew install git-flow-avh

Macports

port install git-flow-avh

Linux

apt-get install git-flow

در ویندوز روش هایی که توضیح داده میشه یکمی درد سر داره من روش خودم رو توضیح میدم:

ابتدا وارد این لینک بشید و هرچی توی صفحه میاد رو کپی کنید، هر جایی از سیستم عامل که هستید یک فایل متنی بسازید با نام دلخواه خودتون بعدش کل این متنی که کپی کردید رو داخلش قرار بدید سپس پسوند فایل رو از txt به sh تغییر بدید روش دوتا کلیک کنید و تمام نصب میشه براتون.

حالا پروژه ای که از قبل دارید یا میخواد بسازید رو از طریق terminal وارد مسیرش بشید و دستور زیر رو بزنید:

git flow init

چند تا سوال ازتون میپرسه احتمال میده که شما نام هایی جز نام های پیش فرض رو بخواید داشته باشید ولی معمولا هیچکس این کارو نمیکنه همه رو Enter بزنید تا بره خط بعد هرچی آورد شما هی Enter بزنید :)

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

بخش سوم Git Flow Features

خب فرض کنید که میخواید یک ویژگی جدید به پروژه اضافه کنید طبیعطا قبلا هیچ برنامه ای برای این کار نداشتید و یا روی مستر کار میکردید یا خلاصه یه جوری ماست مالیش میکردید :d، اما حالا دیگه گیت فلو رو بلدید کافیه ببینید میخواید چه فیچری رو به برنامه اضافه کنید مثلا من میخوام صفحه login رو اضافه کنم پس این دستور رو میزنم:

git flow feature start login

اگر موقع نصب به حرفم گوش کرده بودید و همه رو Enter می زدید الان یک برنچ از روی develop براتون ساخته میشد با نام feature/login و سویچ میشد روی همین برنچ یعنی به محضی این دستور رو بزنید میتونید شروع کنید فیچر لاگین رو پیاده سازی کنید

خب حالا کار من تقریبا تموم شده یا از قبل به صورت مداوم کامیت زدم یا فرض میکنیم که اولین کامیتم هست روی این برنچ از خود گیت استفاده میکنم و با دستور زیر یک کامیت با نام finish اضافه میکنیم:

git commit -a -m &quotfinish&quot

و الان میخوام اعلام کنم که کارم تمومه و لاگین رو زدم میام با دستور زیر این کارو به گیت فلو اعلام میکنم

git flow feature finish login

کارایی که انجام میشه: اول میاد برنچ feature/login رو با develop مرج میکنه و بعدش سویچ میشه روی develop و بعدش هم feature/login رو حذف میکنه.

حالا هی شما با ترس و لرز بیا مرج بز آی این نپره آی اون نپره ! بله دوست من ساده فکر کن چرا سختش میکنی :)

خب حالا اینقدرم ساده نیست بیاید یکم سختش کنیم اگر لازم بود یکی از همکارام بیاد کمک من باید چیکار کنم؟ خب اینجا میایم و همون فیچری رو که کار میکنیم رو روی origin میفرستیم با دستور زیر:

git flow feature publish login

حالا توی سیستم همکارمون کافیه توی سورسش دستور زیر رو بزنیم تا فیچر ما براش بیاد

git flow feature track login

تمام، از این به بعد میتونید با همون commit / push قبلی روی این فیچر باهم کار کنید و لذت ببرید هرکی آخرین نفر کارش تموم شد finish رو بزنه. یادتون باشه برای finish زدن باید آخرین نسخه ای که push شده روی origin روی سیستم شخص finish کننده باشه یعنی اول pull کنه بعد finish.

حالا شاید براتون سوال باشه در تیم های کوچیک دو نفری دارین کار میکنید یکی حواسش نباشه یک فیچر رو finish کنه تکلیف اونی که داره روش کار میکنه چی میشه؟

1- نفر دیگه نمیتونه به هیچ وجه finish کنه چون برنچ feature/login که روی origin رو با finish کردنش حذف کرده
2- فقط میتونه دوباره پابلیش کنه و دوباره فینیش بزنه (به هیچ وجه توصیه نمیشه)

پس نیازه که زحمت بکشید اینقدر پروژه مردم رو با بیخیالی پیش نبرید مثال بارز "چاه مکن بهر کسی اول خودت بعدا کسی" XD

اما در تیم های بزرگ تر چه باید بکنیم؟ در تیم های بزرگ تر معمولا یک هد تیم وجود دارد که شما فیچر رو استارت میزنید و هیچ دسترسی برای push کردن روی develop ندارید صرفا میتونید pull کنید و زمانی فیچر تمام میشود مثلا اگر روی gitlab کار کنید یک merge request میفرستید برای هد تیم و آن شخص مشابه همین شرایط git-flow را در خود gitlab دارد و درصورت تایید کد های شما برنچ شمارا پاک میکند و آن را به مستر مرج میکند، به همین قشنگی :) لازم به ذکره ممکنه توی هر تیم یک جور کار بشه این حالت ایده آل و مطلوبی هست.

این موارد که یهو یک نفر یادش بیاد و غیره مربوط به Hotfixes میشه که جلوتر توضیح میدم

بخش چهارم Git Flow Release

حالا میخوایم ریلیز و نسخه نهایی لاگین به همراه چندین فیچر دیگه رو تحویل بدیم فرض کنید همه تیم فیچر هارو merge request زدن و همه هم accept شده حالا مرحله بعدی ما چیست؟

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

git flow release start v1.0.0 [BASE]

در قسمت [Base] میتونید بر اساس یک Hash از کامیت خاص نسخه بسازید اگر مثلا خیلی جلوتر از نسخه ای که مشتری میخواد هستید میتونید از چند نسخه عقب تر بهش یک نسخه بدید، میتونید هم کلا نزاریدش (پیشنهاد میشه) تا بر اساس آخرین کامیت کارشو انجام بده.

حالا این دستور چیکار میکنه میاد یک برنچ با همون ورژنی که جلوش دادید براتون میسازه یعنی میشه release/v1.0.0 به همین سادگی

تا اینجای کار همه چیز لوکال بوده حالا میخوایم این ورژن صرفا توی سیستم ما نباشه با بقیه تیم بتونیم بررسیش کنیم

با دستور زیر میتونیم بفرستیمش روی origin:

git flow release publish v1.0.0

با دستور زیر هم میتونیم یک نسخه رو از origin ترک کنیم:

git flow release track v1.0.0

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

git flow release finish v1.0.0

وقتی این دستور رو میزنید کار هایی که انجام میده:

1- برنچ release/v1.0.0 مرج میشه به داخل master
2- براتون یک تگ میسازه که این نسخه رو بدونید چه تغییراتی توش دادید یهو بعد از اینکه این دستور رو میزنید یک صفحه میاد این صفحه ادیتور لینوکسی vim هست عکس زیر:

چیزایی که نوشته:

#
# یک پیغام برای تگ بنویسید:
#        ورژن شما v1.0.1
# خط هایی که با # شروع بشوند درنظر گرفته نمیشود
~
~
~
.....

برین به انتهای خط چهارم همونجایی با igoured. تموم شده و کلید insert رو بزنید تا بتونید متن درج کنید و اینتر بزنید هرچی راجب این نسخه میدونید بنویسید مثلا من مینویسم

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

:wq

یعنی دو کامند write و quit رو انجام بده و خارج شو

حالا نیاز داریم که تگ رو برای origin هم بفرستیم فعلا local هست با دستور زیر ارسالش میکنیم برای origin:

git push origin --tags

حالا اگر بریم داخل تگ های ریپازیتوری پروژه رو بررسی کنیم میبینیم که دقیقا با همون توضیحاتی ما نوشته بودیم یک تگ ایجاد شده و بعدش لازمه که master و روهم push کنیم

نکته: وقتی تگ میسازیم میتونیم مجموعه ای از کامیت هارو ذخیره کنیم و از این به بعد میتونیم بفهمیم بین تگ v1.0.0 و تگ v1.0.1 چه تغییراتی صورت گرفته نسبت به نسخه قبلیش؛ همچنین تگ ها برای ci-cd هم استفاده های زیادی داره که خارج از حوصله این مقاله هست مثلا میشه تعریف کرد زمانی که تگ ایجاد میشه همزمان روی سروی هم پروژه deploy بشه ولی اگر توی develop هستیم دیگه فقط تست ها پاس بشه، یا مثلا قبل اینکه یکی برامون merge request بفرسته میتونیم بفهمیم که یه وقت گولمون نزده باشه تست هاش پاس نشده باشه از دست ماهم در بره.

بخش پنجم Git Flow Hotfixes

شما زمانی که Hotfixes نیاز دارید که

• یک نسخه release کردید و تگ خورده و رفته روی مستر.
• مشتری یک مشکلی رو گزارش میده بهتون که شما آپلود کردید پروژش رو میگه همین الان میخام این مشکل رو حل کنید اما شما وسط توسعه بخش دیگری هستید
• در حالت حرفه ای پروژه رو دپلوی کردید با ci-cd میبینید که مثلا تست x در حالت production به مشکل میخوره پس اینجا باید Hotfixes بزنید.

به صورت کلی Hotfixes با مستر کار میکنه زمانی که شما ریلیز میدید کل develop رو به داخل مستر مرج میکنید، 3 مورد مثال زدم که کامل متوجه بشید

حالا فرض میکنیم پروژه رو دپلوی کردیم سروری که پروژه درونش قرار گرفته مشکلی داره که نمیتونه به سرویس پیامکی ما با دامنه خاص وصل بشه مثلا سرور درون آمریکا باشه و دامنه ir تحریم باشه حالا سرویس پیامکی ماهم کار نخواهد کرد بریم باهم که Hotfixes کنیمش:

git flow hotfix start v1.0.3 [BASENAME]

قسمت [BASENAME] این امکان رو بهتون میده که مثلا بتونید یک feature رو Hotfixes کنید یا به صورت مستقیم develop رو اما این کارو نکنید و کلا این فلگ رو قرار ندید تا از روی مستر این کارو انجام بده.

مثلا زمانی که اپلیکیشن موبایل ریلیز میشه دیگه کسی نمیتونه بره یک قسمت خاص رو توی گوشی افراد رفع کنه بگه feature لاگین مشکل داشته یک نسخه کاملا جدید بجای قبلی ارائه میکنند البته اگر برنامه نویس موبایل اپلیکیشن هستید در موارد خاص با code push میشه ولی رسالت بازم همونه.

یا فرض کنید درون پروتکل HTTP همه داده هارو با GET بفرستید و Query Params شدنی اما کلا اشتباه نکنید این کارو آقا بزارید از روی مستر بسازه و تا زماااانی که یک فیچر مطمئن نشدید تموم شده پاکش نکنید.

همونطور که گفتم مثل اپلیکیشن اندروید که میگن توی نسخه beta یا نسخه rc یا هرچی باگ فلان رفع شده اینجا هم جلوی start باید یک ورژن جدید بزنید من تا الان 2 تا ورژن رفع باگ زدم (ورژن گذاری قواعد خاصی داره باید برید مطالعه کنید هر عدد مسئول یک کاری هست) این دفه ورژن جدیدم رو v1.0.3 زدم که از قبلم وجود نداشت؛ میشه گفت ورژن ها همون تگ ها هست نمیزاره تگ تکراری بسازید.

بالاخره این رفع مشکل استارت میشه یک برنچ با نام hotfix/v1.0.3 ایجاد میشه و میتونید باگ رو رفع کنید.

حالا فرض کنیم که باگ رفع شده اگر هد تیم دارید باید برای اون یک merge request بزنید به داخل develop تا ببینه همه چیز درسته و مشکلی نداره بعدش خودش ببره روی مستر.

یا اگر دوسه نفری یا تنها کار میکنید باید دستور زیر رو بزنید:

git flow hotfix finish v1.0.3

اینو که بزنید ادیتور vim باز میشه و ازتون توضیحات تگ یا همون ورژن رو میخواد و بدین صورت این نسخه هم به داخل develop هم به داخل master میره و میتونید پوش بزنید روی origin، همچنین دستور های publish, track و... روی hotfix هم کار میکنه دیگه آسونه خسته تون نمیکنم.

یادتون نشه این تگ v1.0.3 رو روی origin هم بفرستید.

خب احتمالا این آخراش براتون سخت شده بود حالا بزارید تیر خلاص رو بهتون بزنم ما صرفا رفع خطا نداریم صرفا افزودن ویژگی نداریم مثلا ممکنه مشتری بخواد آیکنش عوض بشه این فیچر جدید نمیشه، یا مثلا بخوایم از یک نسخه پشتیبانی بلند مدت کنیم مثل تلگرام بگیم دیگه نسخه 1.1.1 روی هیچ دیوایسی کار نمیکنه این میشه support دیگه اون نسخه رو از لیست ساپورت ها خارج میکنیم، خب این موارد رو از کجا مطالعه کنیم بهتره وارد کامند های خودش بشید و h- بزنید تا راهنمایی کنه مثلا من دستور زیر رو زدم:

git flow -h

خروجی:

usage: git flow <subcommand>
Available subcommands are:
   init      Initialize a new git repo with support for the branching model.
   feature   Manage your feature branches.
   bugfix    Manage your bugfix branches.
   release   Manage your release branches.
   hotfix    Manage your hotfix branches.
   support   Manage your support branches.
   version   Shows version information.
   config    Manage your git-flow configuration.
   log       Show log deviating from base branch.

Try 'git flow <subcommand> help' for details.

توضیحاتشون جلوشون هست که چیکار میکنند هرجارو که گیج شدید میتونید انتهاش یک help بنویسید مثل دستور زیر:

git flow feature help

خواهید دید که چقدر چیز جدید براتون میاره

usage: git flow feature [list]
   or: git flow feature start
   or: git flow feature finish
   or: git flow feature publish
   or: git flow feature track
   or: git flow feature diff
   or: git flow feature rebase
   or: git flow feature checkout
   or: git flow feature pull
   or: git flow feature delete

    Manage your feature branches.

    For more specific help type the command followed by --help

باز میتونید برای هرکدوم جزئیات بیشتری ببینید مثلا:

git flow feature start --help

خلاصه:
1- init دفعه اول که میخواهیم استارت بزنیم
2- feature وقتی میخواهیم ویژگی جدید اضافه کنیم
3- bugfix رفع باگ و مشکل مثلا روی دکمه x کلیک میشود خطا صادر میشود
4- release نهایی کردن نسخه و ورژن گزاری
5- hotfix زمانی که مثلا فراموش میکنیم یک مشکل جزئی مثل وسط چین کردن باتن انجام بدیم
6- support خیلی کاربردی نیست اما زمانی که شما یک نسخه از اپ رو پشتیبانی میکنید معمولا یک نسخه از اون رو درون support نگهداری میکنید تا هروقت خواستید دقیق بررسی کنید ببینید مشکل کاربری که با اون ورژن کار میکنه چیه بتونید به state اون کاربر برگردید همچین چیزی
و بقیه موارد...

امیدوارم پوشش کاملی از Git Flow داده باشم، تقریبا دو روز طول کشید تا کامل و جامع بنویسم

چطور از من حمایت کنید / تقدیر کنید یا تشکر کنید؟ از طریق هر راهی که در توان شما است ❤️

اشتراک گذاری با دوستان یا هم گروهی های خودتان حتی یک گروه کوچک ?

فالو کردن گیت هاب: https://github.com/nbbdev

همچنین میتوانید از طریق صفحه شخصی من در گیت هاب بقیه شبکه های اجتماعی من را دنبال کنید

لایک و کامنت و اشتراک گذاری فراموش نشود که باعث دلگرمی بنده هست ❤️