گیت، اما برای حرفه ای ها!

سلام سلام صد تا سلام!
بالاخره پس از عهد بوقی با مقاله جدید در خدمتتون هستم!

تو این مقاله میخوایم درباره گیت حرف بزنیم، ولی نه گیت معمولی!
میخوایم بریم سراغ یه سری فیچر، اصطلاحات، و ورک فلو ها که تو اکثر آموزش های مقدماتی پیدا نمیشه!
پس بزن بریممممم!!!

چجوری کامیت خوبی بزنیم؟

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

محتوای کامیت:

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

کامیت مسیج:

کامیت مسیج از دو بخش تشکیل شده:

Subject: تایتل اصلی کامیت هستش و فقط باید بنویسیم چه اتفاقی افتاده

تو نوشتن سابجکت کامیت میتونیم از commit conventional استفاده کنیم که یک سری قانون قراردادیه که کمکمون میکنه سابجکت های بهتری بنویسیم

Body: اینجا باید به اتفاقی که افتاده جزئیات بدیم

موقع نوشتن بادی میتونیم این ۳ سوال طلایی رو از خودمون بپرسیم تا بادی بهتری بنویسیم:

• پروژه از کامیت قبلی تا الان چه فرقی کرده؟
• دلیل این تغییر چی بوده؟
• آیا موضوع یا نکته ای هست که باید متوجه و مراقبش باشیم؟

استراتژی برنچ ها:

باشه، گیت به ما یه ابزار داده به اسم برنچ ولی نگفته چجوری ازش استفاده کنیم
به همین خاطر ما باید تو تیممون یک استراتژی برای کار با برنچ ها مکتوب کنیم و همه بهش پایبند باشیم

استراتژی برنچ تو هر تیم و پروژه میتونه متفاوت باشه پس حتما باید آزمون و خطا کنید، در روند پروژه به استراتژیتون فیدبک بدید، و سعی کنید بهترش کنید تا استراژی مناسب خودتون رو بسازید

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

بصورت کلی دوتا استراتژی داریم:

Mainline:

تو این روش برنچ هامون خیلی کم هستن و مدام در حال کار روی برنچ های اصلی هستیم
خوبیش اینه که تعداد برنچ کمه و پیدا کردن همه چیز راحته
و بدیش اینه که باید کامیت هایی با تغییرات خیلی کوچیک مدام بزنیم چون نمیتونیم رو برنچی که بقیه هم باهاش کار میکنن تغییرات بزرگی بدیم

بدی بعدی هم اینه که حتما نیازمند یه سیستم تست و qa خوب هستید تا قبل کامیت به خوبی تغییرات رو تست کنن چون همه تغییرات رو دارید در برنچ اصلی پروژه میزنید

Multi Branch:

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

بطور کلی دو مدل برنچ داره این multi branch:

Long Running:

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

Main Line:

هرپروژه حداقل یکی از اینا داره، مثل برنچ master یا main

Integration:

این برنچ مثل برنچ معروف development میمونه که باعث میشه تغییرات مستقیم رو برنچ mainline نره و اول اینجا تست بشه

Short Lived:

توی این برنچ ها بر خلاف برنچ های Long Running یه اتفاقی مثل اضافه شدن فیچر یا فیکس شدن چیزی اتفاق میوفته و بعد از اون دیگه باهاش کاری ندارن و اصطلاحا میمیرن!

استراتژی های معروف:

یک سری استراتژی معروف هست که خیلی از تیم ها دارن ازشون استفاده میکنن، البته اینم بگم که هر تیمی واسه خودش بازم یه مقدار این استراتژی هارو تغییر میده و با شرایط خودشون منطبق میکنه و الزامی بر رعایت ۱۰۰ درصدی این قواعد نیست!

Github Flow:

تو این استراژی ما یدونه mainline داریم و یه سری هم short-Lived برنچ که واسه فیچر هامون میسازیم
خیلی ساده و مینیمال
اطلاعات بیشتر؟ اینجا

GitFlow:

گیت فلو دارای قوانین بیشتریه و دو mainline داره که main و development هستن
به همراه سه مدل Short-Lived به نام های Feature, Release, Hotfix
اطلاعات بیشتر؟ اینجا و اینجا

فیچر های خفن:

بریم یه سری فیچر گیت رو ببینیم که بعضی هاشون خیلی کاربردی هستن و اسمشون رو احتمالا تابحال زیاد شنیدید رو بررسی کنیم و ببینیم چجوری باید باهاشون کار کرد!

Pull Request:

ایده پول رکوئست اینه که وقتی میخوایم قبل مرج کردن برنچمون به mainline نظر بقیه رو هم بدونیم و code review بشیم یه پول رکوئست بدیم تا بقیه بیان و فیدبک بدن بعد مرج کنیم
حالا این قضیه میتونه تو یه تیم اجباری باشه که همیشه باید مرج ها با پول رکوئست انجام بشه یا که اختیاری باشه و به دلخواه مواقعی پول رکوئست بدی

یا مثلا وقتی میخوای یه تغییری تو یه پروژه بدی که اصلا تو جزوش نیسیتی و بهش دسترسی نداری، میتونی بهشون پول رکوئست بدی و اونا هم میبینن تغیراتت رو و تصمیم میگیرن که مرج کنن یا نه

Fork:

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

Merge Conflict:

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

چجوری درستش کنیم؟
اگه از فایل متنی مثل کد استفاده میکنید که خیلی راحت فایل کانفلیکت خورده رو با یه ادیتور باز میکنی و گیت بهت میگه که مشکل از کجاست
کافیه یه جوری ادیت بزنی که هم تغییرات برنچ خودت کار کنه هم تغییرات تو اون برنچی که داری توش مرج میکنی و بعد که کارت تموم شد به گیت میگی این الان اوکیه و گیت هم اونو مرج میکنه

یه سری ابزار هم کلاینت های گیت مثل github desktop دارن تا کمکت کنن مرج کانفلیکت رو راحت تر حل کنی و خودشون یه کار هایی رو اتومات انجام میدن

Merge vs Rebase:

معمولا افراد با مرج آشنا هستن ولی ریبیس نه و دقیق نمیدونن فرقشون چیه، بریم که بفهمیم!

Merge:

مرج اینجوریه که میاد و کل تغییرات یک برنچ رو ادغام میکنه با یک برنچ دیگه
این وسط یه سری روش مختلف برای ادغام داره مثل fast forwarding که میاد بجای متصل کردن برنچ ها به هم کل هیستوری کامیت های برنچ اول رو میبره تو برنچ بعدی
اما تو merge commit میاد و واقعا دو برنچ رو به هم متصل میکنه و تو یک کامیت کل تغییرات اون برنچ رو به برنچ بعدی منتقل میکنه

Rebase:

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

Interactive Rebase:

درباره ریبیس قبلا صحبت کردیم، اینترکتیو ریبیس درواقع ریبیسی هست که ما میتونیم عملکردش رو مقداری شخصی سازی کنیم
موقع ریبیس کافیه -i رو اضافه کنیم تا یه فایل برامون باز کنه و بهمون دسترسی بده که رفتارش رو تغییر بدیم این شکلی

git rebase -i <upstream>

مثلا با ریبیس میشه اسم یه کامیت قدیمی رو عوض کرد
آخرین کامیت رو همونطور که میدونید میشه با Amend تغییر داد ولی کامیت های قبل اون چی؟
کافیه ریبیس اینترکتیو رو ران کنیم تا فایل متنی مخصوصش رو باز کنه
تو اون فایل با نوشتن کلمه کلیدی reword برای کامیت مورد نظرمون میتونیم بهش بفهمونیم که میخوایم این کامیت رو تغییر بدیم، این ریختی:

reword <commit id> <commit message>

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

یا مثلا میتونی چند تا کامیت مجزا رو به یه کامیت واحد تبدیل کنی
اینجوری که جای reword مینویسی squash و سیو میکنی، این ریختی:

squash <commit id> <commit message>

بعد یه اسکرین باز میشه که بگه چه اتفاقاتی داره میوفته و تایید کنی و تمام

Cherry Pick:

چری پیک ایدش اینه که بذاره شما انتخاب کنید چه کامیت هایی از یک برنچ رو میخواید تو یک برنچ دیگه کامیت کنید
استفاده ازش هم راحته، این ریختی:

git cherry-pick <commit id>

Reflog:

رفلاگ یه لاگ خفنه که خیلی اطلاعات زیادی رو بهمون بطور خوشگلی نشون میده
حتی اطلاعاتی که کمکمون میکنه تا برنچ یا کامیت هایی که پاک کردیم رو برگردونیم
حتی اگه یه سری کامیت رو از مستر پاک کرده باشیم با چک کردن Reflog میشه یه جورایی trash bin گیت رو دید و میگه از کجا میشه دوباره چیزایی که پاک شدن رو پیدا کرد و برشون گردوند

git reflog

Sub modules:

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

اطلاعات بیشتر؟ اینجا

جستجو:

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

git log --author=&quotmamad&quot --before=&quot2020-12-31&quot --after=&quot2020-01-01&quot

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

Bisect:

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

منابع:

https://www.youtube.com/watch?v=Uszj_k0DGsg
https://www.youtube.com/watch?v=qsTthZi23VE

اینم از این، تموم شد.
دمتون گرم که خوندید امیدوارم براتون مفید بوده باشه!
تا مقاله های بعد خدانگه دار :)