توسعه گروهی

گفتیم که Git یک Distributed Version Control System است. یعنی میتواند به صورت چند جایگاهی و توزیع شده کار کند. معمولا یک ریپازیتوری مرجع وجود دارد که تمام توسعه دهنده ها تغییرات روی ریپازیتوری های محلی خود را از طریق pull request ها مرتبا با آن هماهنگ( sync ) میکنند.

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

حالا شرکت های بزرگ و کوچک زیادی از git برای توسعه ی خود استفاده می کنند و روشی به نام trunk-based را برای توسعه ی محصول خود بکار میگیرند؛ trunk-based بودن به معنای این است که تغییرات نهایی محصول روی branch ای به نام main (قبلا به آن master نیز گفته می شد.) انجام می شوند و باقی برنچ ها تنها به هدف تست و قرارگیری احتمالی روی main توسعه پیدا میکنند.

ابزار معروفی که به عنوان هسته ی Distributed Version Control System در اکثر پروژه ها در نظر گرفته می شود GitHub نام دارد. در فرآیند Version Control مفهومی به نام workflow وجود دارد که روند انجام یک عملیات را مشخص میکند. در GitHub عملیات اصلی workflow عملیات pull request است.

در pull request workflow ، ریپازیتوری لوکال ما یک fork از ریپازیتوری گیتهاب است که در برنچ های مختلف آن تغییرات مختلفی توسط توسعه دهندگان دیگر انجام میشود که به آنها upstream یا origin نیز میگوییم.

وقتی که یک تغییر در ریپازیتوری لوکال خود انجام میدهیم معمولا بعد از اینکه مطمئن شدیم تغییر ما درست است، تغییرات خود را با دستور git push به یک برنچ روی ریپازیتوری مرجع (روی گیتهاب) منتقل می کنیم. در این زمان اگر بخواهیم برنچ فعلی را به برنچ upstream منتقل کنیم، باید یک pull request بین دو برنچ ایجاد کنیم و دیگر توسعه دهندگان این pull request را بررسی کنند و تصمیمات ضروری و لازم برای اضافه شدن یا نشدن اطلاعات برنچ اولیه به برنچ upstream را بگیرند.

زمانی که یک pull request کاملا رضایت بخش باشد، سرپرست تیم یا یک برنامه نویس ارشد وظیفه ی merge آن را به upstream به عهده می گیرد و سپس تغییرات به upstream منتقل می شوند.

مزیت pull request workflow این است که توسط ابزارهای مختلف پیاده سازی راحتی برای کار با آن انجام شده اما در پروژه های خیلی بزرگ با pull request های زیاد و عدم مدیریت سریع و مناسب آنها احتمال عقب افتادن زمانی و بوجود آمدن conflict(تداخل) بالا می رود.

سر و کله زدن با conflictهای احتمالی اعصاب زیادی میخواهد و تنها چیزی که در آینده به رفع یا جلوگیری از آنها کمک میکند، افزایش تجربه ی شماست! و نهایتا تیم شما باید بتواند به درستی این مسئله را مدیریت کند.