برخلاف سیستمهای کنترل نسخه متمرکز (CVCSها)، ماهیت توزیعشده گیت به شما اجازه میدهد که در همکاری توسعهدهندگان روی پروژهها بسیار انعطافپذیرتر عمل کنید. در سیستمهای متمرکز، هر توسعهدهنده یک گره است که به طور مساوی با یک هاب مرکزی کار میکند. اما در گیت، هر توسعهدهنده میتواند هم گره باشد و هم هاب؛ یعنی هر توسعهدهنده میتواند هم به مخازن دیگر کد بدهد و هم یک مخزن عمومی نگهداری کند که دیگران بتوانند روی آن کار کنند و به آن مشارکت دهند. این موضوع امکانهای گستردهای از جریانهای کاری را برای پروژه و/یا تیم شما فراهم میکند، بنابراین ما چند الگوی رایج که از این انعطافپذیری بهره میبرند را بررسی خواهیم کرد. ما نقاط قوت و ضعف احتمالی هر طراحی را مرور میکنیم؛ شما میتوانید یکی از آنها را برای استفاده انتخاب کنید یا ویژگیهای مختلف را ترکیب کنید.
در سیستمهای متمرکز معمولاً یک مدل همکاری وجود دارد — جریان کاری متمرکز. یک هاب مرکزی یا مخزن وجود دارد که کد را میپذیرد و همه کارهای خود را با آن همگامسازی میکنند. تعدادی توسعهدهنده به عنوان گره — مصرفکنندگان آن هاب — کار میکنند و با آن مکان مرکزی همگام میشوند.
این بدان معناست که اگر دو توسعهدهنده از هاب کلون کنند و هر دو تغییراتی ایجاد کنند، اولین توسعهدهندهای که تغییراتش را به سرور ارسال کند، بدون مشکل میتواند این کار را انجام دهد. توسعهدهنده دوم باید قبل از ارسال تغییرات خود، کار توسعهدهنده اول را با تغییرات خود ادغام کند تا تغییرات توسعهدهنده اول بازنویسی نشود. این مفهوم در گیت همانقدر درست است که در سابورژن (یا هر CVCS دیگری) درست است، و این مدل در گیت به خوبی کار میکند.
اگر شما قبلاً با جریان کاری متمرکز در شرکت یا تیم خود راحت هستید، میتوانید به راحتی با گیت نیز از همین مدل استفاده کنید. فقط کافی است یک مخزن راهاندازی کنید و به همه اعضای تیم دسترسی ارسال (push) بدهید؛ گیت اجازه نمیدهد کاربران تغییرات همدیگر را بازنویسی کنند.
فرض کنیم جان و جسیکا هر دو همزمان شروع به کار میکنند. جان تغییراتش را تکمیل میکند و آنها را به سرور ارسال میکند. سپس جسیکا تلاش میکند تغییراتش را ارسال کند اما سرور آن را رد میکند. به او گفته میشود که در تلاش برای ارسال تغییرات غیرپیشرو (non-fast-forward) است و نمیتواند این کار را انجام دهد مگر اینکه تغییرات را بگیرد (fetch) و ادغام (merge) کند. این جریان کاری برای بسیاری جذاب است چون الگویی است که بسیاری با آن آشنا و راحت هستند.
این مدل محدود به تیمهای کوچک نیست. با مدل شاخهبندی گیت، صدها توسعهدهنده میتوانند به طور همزمان از طریق دهها شاخه روی یک پروژه کار کنند.
چون گیت به شما اجازه میدهد چند مخزن راه دور داشته باشید، امکان استفاده از جریانی وجود دارد که هر توسعهدهنده به مخزن عمومی خودش دسترسی نوشتن دارد و به مخازن دیگران دسترسی خواندن. این حالت معمولاً شامل یک مخزن مرجع است که نمایانگر پروژه “رسمی” است. برای مشارکت در آن پروژه، شما یک کلون عمومی از پروژه ایجاد میکنید و تغییرات خود را به آن ارسال میکنید. سپس میتوانید درخواست دهید که نگهدارنده پروژه اصلی تغییرات شما را دریافت کند. نگهدارنده میتواند مخزن شما را به عنوان یک مخزن راه دور اضافه کند، تغییرات شما را به صورت محلی تست و ادغام کند، و سپس به مخزن خودش ارسال کند. فرآیند به این صورت است (نگاه کنید به Integration-manager workflow):
-
نگهدارنده پروژه تغییرات را به مخزن عمومی خودش ارسال میکند.
-
یک مشارکتکننده آن مخزن را کلون میکند و تغییراتی ایجاد میکند.
-
مشارکتکننده تغییراتش را به نسخه عمومی خودش ارسال میکند.
-
مشارکتکننده ایمیلی به نگهدارنده میفرستد و درخواست میکند تغییرات را دریافت کند.
-
نگهدارنده مخزن مشارکتکننده را به عنوان مخزن راه دور اضافه میکند و تغییرات را به صورت محلی ادغام میکند.
-
نگهدارنده تغییرات ادغام شده را به مخزن اصلی ارسال میکند.
این یک جریان کاری بسیار رایج با ابزارهای مبتنی بر هاب مانند GitHub یا GitLab است که در آن به راحتی میتوان پروژه را فورک کرد و تغییرات را در فورک خود به اشتراک گذاشت. یکی از مزایای اصلی این روش این است که شما میتوانید به کار خود ادامه دهید و نگهدارنده مخزن اصلی هر زمان که بخواهد تغییرات شما را دریافت کند. مشارکتکنندگان نیازی ندارند منتظر بمانند تا پروژه تغییراتشان را بپذیرد — هر طرف میتواند با سرعت خودش کار کند.
این یک زیرمجموعه از جریان کاری چند مخزنه است. معمولاً در پروژههای بسیار بزرگ با صدها همکار استفاده میشود؛ یک مثال مشهور کرنل لینوکس است. چند مدیر ادغام مسئول بخشهایی از مخزن هستند؛ به آنها معاونان گفته میشود. تمام معاونان یک مدیر ادغام دارند که به او دیکتاتور خیرخواه گفته میشود. دیکتاتور خیرخواه از شاخه خودش به مخزن مرجع که همه همکاران باید از آن بگیرند، ارسال میکند. فرآیند به این صورت است (نگاه کنید به Benevolent dictator workflow):
-
توسعهدهندگان معمولی روی شاخه موضوعی خود کار میکنند و کارشان را روی شاخه
masterبازپایه (rebase) میکنند. شاخهmasterمتعلق به مخزن مرجعی است که دیکتاتور به آن ارسال میکند. -
معاونان شاخههای موضوعی توسعهدهندگان را در شاخه
masterخود ادغام میکنند. -
دیکتاتور شاخههای
masterمعاونان را در شاخهmasterخودش ادغام میکند. -
در نهایت دیکتاتور آن شاخه
masterرا به مخزن مرجع ارسال میکند تا سایر توسعهدهندگان بتوانند روی آن بازپایه کنند.
این نوع جریان کاری رایج نیست، اما در پروژههای بسیار بزرگ یا محیطهای سلسلهمراتبی بسیار مفید است. این امکان را به رهبر پروژه (دیکتاتور) میدهد که بخش زیادی از کار را واگذار کند و مجموعههای بزرگی از کد را در چند مرحله جمعآوری و سپس ادغام کند.
|
Note
|
مارتین فاولر راهنمایی به نام "الگوهایی برای مدیریت شاخههای کد منبع" تهیه کرده است. این راهنما تمام جریانهای کاری رایج گیت را پوشش میدهد و توضیح میدهد که چگونه و چه زمانی از آنها استفاده کنیم. بخشی نیز دارد که فرکانسهای بالای ادغام و پایین را مقایسه میکند. |
اینها برخی جریانهای کاری رایج هستند که با یک سیستم توزیعشده مانند گیت امکانپذیرند، اما میبینید که تنوع زیادی برای تطبیق با جریان کاری واقعی شما وجود دارد. اکنون که (امیدواریم) بتوانید ترکیب مناسبی از جریانهای کاری را برای خود مشخص کنید، به بررسی مثالهای مشخصتری از چگونگی انجام نقشهای اصلی در جریانهای مختلف میپردازیم. در بخش بعد، با چند الگوی رایج برای مشارکت در یک پروژه آشنا خواهید شد.