Workflows

سیستم‌هایِ کنترلِ ورژن به دو گروه تقسیم می‌شن:

• Centralized (متمرکز)
• Distributed (توزیع‌شده)

در سیستمِ Centralized (مثلِ subversion) تنها یه دونه repository داریم که با دیگر اعضایِ تیم به اشتراک گذاشته می‌شه. مشکلی که این سیستم داره اینه که تمامیِ اعضایِ تیم به این repository مرکزی وابسته هستن. اگر سروری که این repository رو میزبانی میCentralized کنه آفلاین بشه، هیچ‌کس نخواهد توانست کامیت بکنه و یا تاریخچه‌ی پروژه رو ببینه.

در سیستمِ Distributed (مثلِ گیت) هر توسعه‌دهنده، repository رو در کامپیوترِ خودش داره. دیگه در اینجا وابستگی به سرورِ مرکزی نیست. هر کاربر می‌تونه به صورتِ آفلاین با local repository خودش کار کنه. ولی چطور می‌تونن در این سیستم با هم مشارکت داشته باشن؟

در این سیستم، می‌تونیم کارهامون رو به صورتِ مستقیم با همدیگه synchronize (منطبق) کنیم. ولی این اغلب خیلی پیچیده و مستعد خطاست.

بجاش از Centralized Workflow استفاده می‌کنیم. بنابراین، هرکسی local repository خودش رو خواهد داشت، اما همچنین این افراد یک central repository هم خواهند داشت تا از طریقش بتونن کارشون رو synchronize کنند.

این workflow (روندِ ‌کاری) توسطِ بیشتر تیم‌های خصوصی و پروژه‌هایِ محرمانه استفاده می‌شه. ولی شاید بپرسید که نقطه‌قوتِ این روند کاری چیه؟ چطور این روندِ کاری بهتر از centralized Version Control System هستش؟ خُب، در این طرح، اگر هم central repository از کار بیفته، می‌تونیم رویِ local repository خودمون کار کنیم و کارهامون رو با هم‌تیمی‌هامون مستقیماً sync کنیم.

ما باید central repositoryمون رو داشته باشیم تا همه‌ی تیم بتونن بهش دسترسی داشته باشن. برخی سازمان‌ها repositoryشون رو روی سروری در شبکه‌ی خصوصیِ خودشون قرار می‌دن. برخی دیگر نیز ترجیح می‌دن از سرویس‌هایِ میزبانیِ گیت (Git hosting service) مثلِ GitHub، GitLab، Gitbucket و… استفاده کنند. توسطِ این سرویس‌ها می‌تونیم repositoryمون رو بصورتِ private repository آماده کنیم تا فقط توسطِ اعضایِ تیم‌مون دسترسی داشته باشه.

بریم سراغِ یه سناریوی واقعی. John و Amy روی پروژه‌ای همکاری می‌کنن. این دو، ابتدا با clone کردن یا برداشتن یک کپی از central repository شروع می‌کنن. حالا، هر دو local repository رو روی سیستمِ‌ شخصیِ خودشون دارن.

John شروع به درست کردنِ چند کامیت می‌کنه. Amy هم می‌تونه بصورتِ همزمان کامیت‌هایِ دیگه‌ای رو بسازه. گاهاً John نیازه داره که کارش رو با Amy به اشتراک بذاره. به همین منظور، John از دستورِ push برای فرستادنِ commitهاش به central repository استفاده می‌کنه. حالا central repository با کامیت‌هایِ جان sync شده.

حال، Amy می‌تونه از دستورِ pull استفاده کنه تا کارِ John رو به local repository خودش بیاره. اگه کارِ John با کارِ Amy تداخل داشته باشه Amy می‌تونه اون conflictها رو resolve کنه و سپس تغییرات رو به ریپازیتوریِ مرکزی push کنه.

این روندِ کاریِ توزیع‌شده (Centralized workflow) هست که اغلب توسطِ تیم‌هایِ خصوصی مورد استفاده قرار می‌گیره. هر شخص از تیم، مستقیماً دسترسیِ push به central repository رو داره.

Integration-Manager

روندِ کاریِ دیگه‌ای برای پروژه‌هایِ open source داریم که Integration-Manager Workflow نام داره. در این روندِ‌کاری یک یا چند maintainers (نگه‌دارنده) داریم و چندین Contributor (مشارکت‌کننده).

مشکلی که در این روند‌کاری هست اینه که دیگه در اینجا contributorها رو نمی‌شناسیم. پس نمی‌تونیم به اون‌ها اعتماد کنیم تا این اجازه رو بهشون بدیم تا مستقیم به ریپومون push یا write کنن. فقط maintainerها این دسترسی رو خواهند داشت که به ریپو push کنن.

خب، اگه شما می‌خواهید مشارکت کنید، ابتدا، باید project repository رو fork کنیم تا یک کپی از این repo رو داشته باشیم. بعدش این repo رو clone می‌کنیم تا ازش یک کپی در سیستمِ شخصی‌مون داشته باشیم. چند کامیت می‌سازیم و زمانی که کارمون آماده برای به اشتراک‌گذاری است یه push می‌کنیم تا کامیت‌هامون رو به forked repositoryمون ارسال کنیم.

بعدش یه pull request به maintainer مربوط به پروژه می‌فرستیم. pull request ویژگی‌ای است که در پلتفرم‌هایی مثلِ گیت‌هاب به منظورِ مطلع ساختن بوجود اومده. سپس، maintainer می‌تونه تغییراتِ ما رو pull کنه، بازبینی‌شون کنه و اگه از این تغییرات راضی بود می‌تونه اونها رو با local repository خودش merge کنه و سپس merge change‌ها رو به repository رسمی push کنه.

این Integration-Manager Workflow نامیده می‌شه. چون اشخاصی مسئولِ یکپارچه‌سازیِ تغییرات هستند. نمی‌تونیم در این روندکاری مستقیماً تغییرات رو به ریپویِ رسمی push کنیم. به همین خاطر مجبوریم که اون رو fork کنیم تا یه کپی ازش در کلاود داشته باشیم. چون این ریپو تو کلاود هستش، برای maintainerها هم قابلِ‌رؤیت هست و به همین خاطر اون‌ها می‌تونن تغییرات ما رو pull کنن.