من متوجه شده ام که بسیاری از برنامه نویسان قوانین ذکر شده در زیر را نادیده می گیرند یا از آنها اطلاعی ندارند. با این وجود، پیروی از این قوانین می تواند کار تیم های بزرگ و کوچک را با استفاده از git استاندارد کند، از مشکلات و خطاها در شاخه های توسعه دهنده و در تولید جلوگیری کند.
ذکر این نکته ضروری است که من یک گورو git نیستم و همه دستورات و ویژگی ها را نمی دانم، اما امیدوارم این مقاله مفید واقع شود.
“ما همیشه برای استاد شدن فشار می آوریم”
اولین قاعده ای که باید رعایت شود، جداسازی شاخه ها برای تولید و توسعه است. من معمولا از main و develop شاخه ها. را main شاخه معمولاً با هر تغییر به طور خودکار مستقر می شود، در حالی که develop شاخه برای توسعه استفاده می شود اما هیچ خطایی وجود ندارد و تمام عملکردها تکمیل شده است.
همانطور که در نمودار نشان داده شده است، هر گونه تغییر در main شعبه فقط از develop شاخه (که ممکن است به محیط آزمایشی مرتبط باشد)، اما هیچ کس مستقیماً با آن کار نمی کند develop شاخه. هر کار باید با ارث بردن از develop و ایجاد شعبه جدید هر اصلاحی باید در یک شاخه جداگانه ایجاد شود و سپس در آن ادغام شود develop.
در مواردی که یک کار بر یک عملکرد بزرگ تأثیر می گذارد، به خصوص اگر نیاز به مشارکت چندین توسعه دهنده داشته باشد، لازم است از توسعه به یک شاخه جداگانه “EPIC” ارث بری شود. آنها می توانند اعداد متوالی داشته باشند EPIC-100، EPIC-101 … یا منعکس کننده اصل است EPIC-notifications. هر توسعه‌دهنده‌ای که روی این «EPIC» کار می‌کند باید از آن به ارث برده و وظیفه تکمیل‌شده خود را مستقیماً در آن ادغام کند.
با این سلسله مراتب، واگذاری وظایف به توسعه دهندگان سطوح مختلف امکان پذیر می شود. به عنوان مثال، می توانید اجازه دهید فشار به develop فقط برای رهبران تیم و برنامه نویسان ارشد. و برای برخی از وظایف، می توانید کنترل کامل EPIC ها را به توسعه دهندگان میانی بدهید تا بتوانند ادغام وظایف جوانان را کنترل کنند و مسئولیت کیفیت کد در EPIC را بر عهده بگیرند. این باعث می شود که خطاها به حداقل برسد و مسئولیت پروژه بین همه توسعه دهندگان با توجه به توانایی های آنها توزیع شود. و شعبه شما همیشه مال شما خواهد بود – عدم همگام سازی ناگهانی سرور محلی و راه دور به دلیل فشارهای غیرهمگام برنامه نویسان مختلف اتفاق نخواهد افتاد.
چیزی اشتباه است – ما باید به عقب برگردیم
گاهی اوقات یکی از توسعه دهندگانی که روی یک پروژه کار می کند ممکن است به طور تصادفی تغییرات نادرستی (به دلیل بی تجربگی، بی دقتی یا صرفاً به این دلیل که تغییرات او تأثیر منفی بر توسعه محلی نداشته است) ارائه دهد. و گاهی اوقات پیدا کردن و رفع علت اشکالات و خطاهای تازه ظاهر شده بسیار دشوار است.
اخیراً شاهد وضعیتی بودم که پس از 8 commit در بالای آخرین نسخه صحیح برنامه و بیش از 200 فایل تغییر یافته، یک خطای مبهم رخ داد.
در چنین مواردی، عقب نشینی ضروری است.
فرض کنید باید 2 commit آخر را برگردانیم، که معتقدیم حاوی خطا هستند. این کار به 2 روش قابل انجام است:
git revert HEAD~2..HEAD
که 2 commit جدید ایجاد می کند که تغییرات commit های قبلی را خنثی می کند. این بدان معنی است که تاریخچه commit بدون تغییر باقی می ماند (تعهدات جدید با تغییرات اضافه می شوند).
git reset --hard HEAD~2
که تغییرات ایجاد شده در یک یا چند commit را خنثی می کند و آنها را به طور کامل از تاریخچه commit حذف می کند.
!!! من به شدت توصیه می کنم از گزینه دوم استفاده نکنید !!!
اولاً، commitهایی را که در آنها علاوه بر خطا، ممکن است کدهای مفیدی توسط توسعه‌دهندگان دیگر نوشته شده باشد، به‌طور دائم حذف می‌کند که ممکن است برای ایجاد commitهای جدید پس از بازگشت نیاز باشد.
ثانیاً، این بدون شک باعث مشکلات همگام سازی با توسعه دهندگان دیگر می شود، زیرا تاریخچه commit در مخزن راه دور تغییر خواهد کرد.
برای خلاصه کردن – استفاده کنید git revert،
…یا git reset --hard، اما شما باید بفهمید که چه کار می کنید.
تعهد و ادغام مناسب
چنین موقعیت هایی باید به ندرت اتفاق بیفتد و باید تا حد امکان به حداقل برسد.
1) برای انجام این کار، همیشه باید بفهمید که چه چیزی را به مخزن راه دور فشار می دهید و دستور را فراموش کنید. git add . برای همیشه. در عوض از UI IDE خود برای اضافه کردن فایل ها به commit استفاده کنید. در VSCode و WebStorm می توانید تمام فایل های اصلاح شده را مشاهده کرده و کلیک کنید + در مورد آنهایی که مطمئن هستید تغییرات، ضربه زدن تصادفی کلید نبوده، بلکه تغییرات معنی دار شما بوده است.
2) کد موجود در شعبه شما باید برای هر تغییر کوچک اما کامل تعهد شود. و پیام commit باید حاوی اطلاعات کافی باشد: شماره یا نام وظیفه و شرح مختصری از کاری که انجام داده اید. به عنوان مثال، “اعلان ها – ایجاد یک کلاس برای اتصال به وب سوکت ها.”
3) اما در شاخه های EPIC و سایر شاخه های مشترک که کامیت شما ادغام می شود، باید فقط یک commit با اشاره به شاخه شما وجود داشته باشد. برای انجام این کار، ادغام در این شاخه باید با پرچم ها انجام شود --no-commit و --squash.
# In a some EPIC branch:
git merge your-branch --no-commit --squash
این دستور بلافاصله شاخه شما را ادغام نمی کند، بلکه فقط تمام تغییرات را از شاخه شما به شاخه مشترک اعمال می کند. می‌توانید آنها را در UI IDE خود مشاهده کنید و دوباره بررسی کنید که آیا از هر فایل اصلاح شده در شاخه مشترک مطمئن هستید یا خیر. پس از آن، می توانید با توضیحاتی که شامل نام شعبه و نام شاخه ادغام شده است، commit کنید. به عنوان مثال، “Site-sidebar – Notifications ادغام شد.”
4) پس از ادغام در شاخه اشتراکی، به خصوص در شاخه توسعه، باید عملکرد ویژگی خود و مناطقی را که فکر می کنید ممکن است تحت تأثیر تغییرات کد شما قرار گرفته باشد را آزمایش کنید. اگر همه چیز به درستی کار می کند، می توانید شاخه مشترک را با commit merge به مخزن راه دور فشار دهید.
5) ادغام در توسعه باید به همان روشی که در بالا توضیح داده شد انجام شود. شاخه‌های EPIC که قبلاً تأیید شده‌اند، می‌توانند شامل تعهدات زیادی برای هر کار تکمیل‌شده باشند. اکنون هر EPIC باید با یک commit ادغام شود تا توسعه یابد. “سایت-نوار کناری ادغام شد”. پس از مدتی، زمانی که وظایف در عمل ارزش خود را ثابت کردند، شاخه های وظیفه را می توان از مخزن حذف کرد (این کار را می توان پس از یک دوره مشخص، به عنوان مثال، 1-2 ماه، بسته به سرعت کار تیم شما انجام داد).
فراموش نکنید که از کلمه “ادغام شده” در توضیحات استفاده کنید تا commit های معمولی را از ادغام متمایز کنید
تعدادی نکته
1) نوشتن دستورات Git با همه پرچم ها و پارامترها می تواند برای برنامه نویسانی که عادت به تایپ کورکورانه با 10 انگشت ندارند خسته کننده باشد، به خصوص اگر مجبور باشند دائماً آنها را وارد کنند.
من شخصاً از OhMyZsh برای ساده کردن برخی از دستورات استفاده می کنم. اگر کاربر ویندوز نیستید، به شدت آن را توصیه می کنم. مثلا:
gcmsg 'first commit'
# This is the same as
# git commit -m 'first commit'
gco develop
# git checkout develop
gcb new-branch
# git checkout -b new-branch
2) اگر مانند من از VSCode استفاده می کنید، به پسوند Git Graph نگاهی بیندازید. تایپ کردن در کنسول همیشه سریعتر از استفاده از ماوس برای پیمایش است، اما گاهی اوقات سخت است که خود را در پروژه بدون یک رابط کاربری گرافیکی خوب جهت دهی کنید.
3) حتی با این ساختار کاری هم مشکلات و خطاهایی به وجود می آید. و در اینجا بسیار مهم است که بفهمید چگونه برقراری ارتباط برای شما آسان تر است:
- نظراتی را در مورد وظایف تکمیل شده در مدیران وظیفه خود با شرح وضعیت فعلی شعبه بنویسید (احتمالاً با شرح خطاهای جدید و اسکریپت های لازم برای اجرای برنامه)،
- خود را در پیام رسان ها در مورد وضعیت خود علامت گذاری کنید
- جلسات عمومی خود را به جلسات کوچکتر تقسیم کنید – برای کسانی که روی یک حماسه خاص کار می کنند.
