? مراقب باشیم!
زﻣﺎﻧﯽ ﮐﻪ ﻣﺒﺤﺚ workflow ﻣﻄﺮح ﻣﯿﺸﻪ، ﺗﺼﻤﯿﻢﮔﯿﺮی اﯾﻦ ﻣﻮﺿﻮع ﺧﯿﻠﯽ ﺑﺴﺘﮕﯽ ﺑﻪ ﻓﺮﻫﻨﮓ ﺗﯿﻢ ﯾﺎ culture داره. ﺑﺎ اﺿﺎﻓﻪ ﺷﺪن workflow اﯾﻦ اﻧﺘﻈﺎر ﻣﯿﺮه ﮐﻪ، ﮐﺎراﯾﯽ ﺗﯿﻢ اﻓﺰاﯾﺶ ﭘﯿﺪا ﮐﻨﻪ! ﮔﺮدش ﮐﺎر ﻣﯿﺘﻮﻧﻪ ﯾﻪ مسئولیت اﺿﺎﻓﻪ روی ﺗﯿﻢ اﯾﺤﺎد ﮐﻨﻪ و ﻃﺒﯿﻌﺘﺎ ﮐﺎﻫﺶ productivity در ﺗﯿﻢ و ﻣﺤﺼﻮل رو ﺑﻬﻤﺮاه داره.
برای انتخاب استراتژی مناسبِ تیم و محصول خودمون، باید این موارد رو درنظر بگیریم:
? آیا این workflow مناسب سایز تیم یا محصول من هست؟
? اگه به اشتباه یا خطایی برخورد کردم، این workflow به داد من میرسه؟
? آیا این workflow با اضافه شدنش، سربار ذهنی غیرضروری جدیدی به تیم وارد میکنه؟
میشه گفت این استراتژی در git، ساده ترین روش برای مدیریت codebase محصول به حساب میاد. در این روش، یک default branch وجود داره و اون master نامیده میشه. در این روش فقط یک نقطه ی ورود برای همه ی تغییرات در پروژه وجود دارد. درسته که این روش فرق چندانی با نگهداری کد بصورت local نداره، ولی باعث میشه برنامه نویس ها فارق از بقیه ی تغییرات اعمال شده توسط بقیه افراد تیم، بتونن کد بزنن و فیچر خودشون رو به repository اضافه کنند.
#نظرشخصی: این روش بنظر من واسه تیم های کوچک و کمتر از ۵ نفر مناسبه
⚫️ ایجاد تغییرات و commit
زمانی که توسعه دهنده repository رو clone میکنه، میتونه با استفاده از فرآیند های گیت مثل edit،stage،commit تغییرات جدیدی رو بصورت local در repository اعمال کند.
برای بررسی تغییرات میتوانید از این دستور استفاده کنید:
⚫️ انتقال کامیت های جدید به central repository
زمانی که تغییرات جدیدی در local repository کامیت شد، نیازه که این تغییرات با بقیه ی برنامه نویس های محصول، به اشتراک گذاشته شود.
با اجرا کردن این فرمان کامیت های جدید، در برنچ master که از اون بعنوان central repository استفاده میکنیم، push میشه. این احتمال وجود داره که تغییرات جدید کد، باعث بشه هم تیمی شما هنگام push کردن کدهای جدید به خطای مغایرت یا conflict error برخورد کنه!
⚫️ اولین راهِ چاره
اولین راهکار برای رفع conflict در این شرایط اجرای git pull هست که در ادامه راهکار جامع تری رو توضیح میدم.
⚫️ مدیریت conflicts
اگه local commit های توسعه با central repository هم‌خوانی نداشته باشه، گیت از push کردن تغییرات خودداری میکنه به این دلیل که این امکان وجود داره که central repository دچار overwrite شود.
? یک مثال از این ورک‌فلو
بیایید یک مثال کلی در مورد چگونگی همکاری یک تیم کوچک معمولی با استفاده از این گردش کار بیاوریم. خواهیم دید که چگونه دو برنامه نویس ، John و Mary ، می توانند روی ویژگی های جداگانه کار کنند و مشارکت های خود را از طریق یک مخزن متمرکز به اشتراک بگذارند.
توسعه feature توسط John
در local repository خود ، John می تواند فیچر خود را با استفاده از فرآیند استاندارد Git توسعه دهد. به یاد داشته باشید از آنجا که این دستورات کامیت های local را ایجاد می کنند ، John می تواند این روند را هر چند بار که بخواهد تکرار کند بدون اینکه نگران تغییرات موجود در central repository باشد.
توسعه feature توسط Mary
در همین حال ، Mary با استفاده از همان فرایند در حال کار بر روی feature خود در local repository خود است. برای Mary مانند John مهم نیست که در central repository چه می گذرد و اهمیتی ندارد که John مشغول چه کاری است. زیرا همه repository ها local و خصوصی هستند.
انتشار feature توسط John
هنگامی که John فرآیند توسعه ی feature خود را به پایان رساند باید local commit های خود را در central repository منتشر کند تا سایر اعضای تیم بتوانند به آن دسترسی پیدا کنند. او می تواند این کار را با دستور git push انجام دهد:
انتشار feature توسط Mary
بیایید ببینیم اگر Mary سعی کنه feature خود را انتشار دهد، پس از اینکه John با موفقیت تغییرات خود را در central repository منتشر کرد ، چه اتفاقی می افتد. اون نیز مانند John از دستور git push استفاده میکند ولی با خطا مواجه میشود:
استفاده از rebase توسط Mary
کاری که Mary میتواند انجام دهد استفاده از git pull است. با این کار تغییراتی که قبلا John در central repository منتشر کرده است، به local repository مری انتقال می‌یابد و کامیت های John هم با کامیت های Mary ادغام میشود:
در دستور بالا، با اضافه کردن rebase-- پس از یکسان سازی local repository با central repository، تمام کامیت های Marry به ابتدای برنچ master انتقال می‌یابد:
رفع یک تداخل ( merge conflict ) توسط Marry
فرآیند rebasing با انتقال هر کامیت local به برنچ master انجام میشود. این به این معناست که تداخلات کد بجای حل شدن در یک merge commit بزرگ، کامیت به کامیت حل میشوند. این قابلیت به نگهداری تمیز تر کد کمک زیادی میکند. از طرف دیگر، این امر باعث میشود که ریشه ی اشکالات را راحت‌تر پیدا کنید و درصورت نیاز، بازگرداندن تغییرات ( roll back ) با کمترین تاثیر بر روی پروژه و محصول انجام شود.
اگر Mary و John روی دو feature مختلف کار کنند، بعید بنظر میرسد که روند rebasing دچار تداخل شود. درغیر اینصورت git فرایند را با این پیام متوقف میکند:
نکته ی جالب در مورد git این است که هر کس میتواند merge conflict خود را حل کند. در مثال ما، Mary به سادگی با اجرای git status میتواند فایل های دارای تداخل را در بخش Unmerged paths مشاهده کند:
سپس فایل (ها) را همانطور که میخواهد ویرایش میکند. زمانی که به نتیجه ی مطلوب رسید، میتواند فایل ها را به stage اضافه کند و اجازه دهد git rebase بقیه ی کاراها را انجام دهد:
این تنها کاری است که باید انجام شود. git به commit بعدی میرود و این فرایند را تکرار میکند تا همه ی تداخلات برطرف شود.
اگر در این فرآیند به مرحله ای رسیدید که نمیدانید چخبر است، وحشت نکنید! فقط دستور زیر را اجرا کنید و به همان مکانی که شروع کردید برمیگردید:
انتشار موفق feature توسط Mary
بعد از انجام مراحل قبل و همگام سازی هر دو ریپوزیتوری ( local و central ) Mary میتواند تغییرات خود را با موفقیت منتشر کند.
در پست های آینده راهکار های مناسب تیم های بزرگ تر را ارائه میکنم.
