گردش کار Git یک دستورالعمل یا توصیه برای نحوه ی استفاده از Git است که کاربران را تشویق می کند تا به طور موثر و مداوم از Git استفاده کنند. Git انعطاف پذیری زیادی در نحوه ی مدیریت تغییرات کاربران ایجاد می کند. چندین گردش کار Git وجود دارد که ممکن است برای تیم شما مناسب باشد که در این مقاله به گردش کار Forking که یکی از این گردش کارهاست خواهیم پرداخت.
این گردش کار تفاوت اساسی با سایر گردش کار های محبوب Git دارد. در این گردش کار به جای اینکه از یک مخزن سمت سرور استفاده شود تا به عنوان پایگاه کد "مرکزی" عمل کند، به هر توسعه دهنده یک مخزن سمت سرور اختصاصی داده می شود. این به این معنی است که هر شرکت کننده دو مخزن Git دارد؛ یکی محلی خصوصی و دیگری سمت سرور عمومی. گردش کار forking اغلب در پروژه های متن باز عمومی دیده می شود.
مزیت اصلی گردش کار Forking این است که هر شرکت کننده بدون نیاز به push کردن هر تغییر یا ویژگی به مخزن مرکزی یکپارچه، می تواند آن ها را merge کند. توسعه دهندگان فقط دسترسی push به مخزن سمت سرور خود را دارند و فقط نگهدارنده های پروژه، دسترسی push به مخزن اصلی را دارند. این به مدیران اجازه می دهد که commit های توسعه دهندگان را بدون نیاز به دادن دسترسی به پایگاه کد اصلی بپذیرند.
گردش کار Forking به طور معمول از مدل شاخه بندی مبتنی بر گردش کار Gitflow پیروی می کند. این به این معنی است که شاخه های feature پس از کامل شدن، برای merge شدن در مخزن نگه دارنده ی اصلی پروژه در نظر گرفته شده اند. در نتیجه یک گردش کاری نامتمرکز به وجود می آید که روشی انعطاف پذیر برای یک همکاری ایمن در تیم های بزرگ است. این امر همچنین گردش کار Forking را به یک گردش کار ایده آل برای پروژه های منبع باز تبدیل می کند.
گردش کار Forking چگونه کار می کند؟
همانند سایر گردش های کاری Git، گردش کاری Forking هم، با یک مخزن عمومی رسمی ذخیره شده در یک سرور آغاز می شود. اما وقتی یک توسعه دهنده جدید می خواهد روی پروژه کار کند، مستقیما مخزن رسمی را clone نمی کند. در عوض مخزن رسمی را fork می کند تا نسخه ای از آن را در سرور خود ایجاد کند. این به عنوان مخزن عمومی شخصی او عمل می کند، هیچ توسعه دهنده ی دیگری مجاز به push در آن نیست، اما آن ها می توانند تغییراتی را از آن pull کنند. بعد از اینکه نسخه سمت سرور برای توسعه دهنده ایجاد شد، او باید دستور Git clone را اجرا کند تا نسخه ای از آن را بر روی دستگاه محلی خود قرار دهد. این امر همانند سایر گردش کارها به عنوان محیط توسعه خصوصی آنها عمل می کند. هنگامی که توسعه دهندگان آماده ی انتشار یک commit محلی هستند، آنها این commit را به مخزن عمومی خود push می کنند نه مخزن عمومی رسمی. سپس، یک درخواست pull با مخزن اصلی ثبت می کنند، که مدیر پروژه را متوجه می کند که یک به روز رسانی برای merge آماده است. موارد زیر مثالی گام به گام از این گردش کار است:
1. یک توسعه دهنده، مخزن رسمی سمت سرور را fork کرده که این کار یک کپی سمت سرور برای او ایجاد می کند.
2. نسخه ی جدید از مخزن سمت سرور در سیستم محلی آن کپی می شود.
3. یک آدرس remote Git برای مخزن "رسمی" به clone محلی اضافه می شود.
4. یک شاخه ی feature جدید محلی ایجاد می شود.
5. توسعه دهنده در شاخه جدید تغییراتی ایجاد می کند.
6. یک commit جدید برای تغییرات ایجاد می شود.
7. شاخه به کپی مخزن سمت سرور توسعه دهنده، push می شود.
8. توسعه دهنده یک درخواست pull از شاخه جدید را به مخزن "رسمی" می دهد.
9. درخواست pull برای merge تایید می شود و در مخزن اصلی سمت سرور merge می شود.
برای merge این ویژگی در پایگاه کد رسمی، maintainer تغییرات مشارکت کننده را در مخزن محلی خود pull کرده و پس از بررسی این که تغییرات باعث خرابی در پروژه نشده باشد آن را در شاخه ی master خود merge می کند و سپس شاخه master را در مخزن رسمی سرور push می کند. این مشارکت اکنون بخش جدیدی از پروژه است و توسعه دهندگان دیگر باید از مخزن رسمی برای همگام سازی مخازن محلی خود استفاده کنند.
مهم است که درک کنیم مفهوم مخزن "رسمی" در گردش کار Forking صرفاً یک قرارداد است. در حقیقت، تنها چیزی که مخزن رسمی را بسیار رسمی می کند این است که مخزن عمومی برای maintainer پروژه است.
Forking در مقابل Cloning
عملیات clone اساسا به معنی کپی مخازن و تاریخچه ی آن است. توجه به این نکته مهم است که fork کردن مخازن عملیات خاصی نیست. مخازن fork شده با استفاده از دستور استاندارد Git clone ایجاد می شوند. هیچ دستور منحصر به فرد Git برای ایجاد مخازن fork شده وجود ندارد. مخازن fork شده "کپی های سمت سرور" هستند که معمولا توسط سرویس های شخص سوم Git مانند GitHub مدیریت و میزبانی می شوند.
Branching در گردش کار Forking
همه این مخازن شخصیِ عمومی، واقعاً فقط یک روش مناسب برای به اشتراک گذاشتن شاخه ها با توسعه دهندگان دیگر است. همه همچنان باید از شاخه ها برای جدا کردن feature های فردی استفاده کنند، دقیقاً مانند گردش کار Feature Branch و گردش کار Gitflow. تنها تفاوت در نحوه ی اشتراک شاخه ها است. در گردش کار Forking، شاخه ها به مخزن محلی توسعه دهنده ی دیگر pull می شوند، در حالی که در گردش کار Feature Branch و گردش کار Gitflow به مخزن رسمی push می شوند.
Fork کردن یک مخزن
تمام توسعه دهندگان جدید یک پروژه گردش کار Forking نیاز به fork کردن مخزن رسمی دارند. همانطور که قبلاً گفته شد، fork کردن فقط یک عمل استاندارد Git Clone است. این کار را می توان با SSH موجود در سرور و اجرای دستورهای Git Clone انجام داد تا مخزن را در مکان دیگری از سرور کپی کرد.
کپی کردن مخزن Fork شده
در مرحله ی بعدی، هر توسعه دهنده باید مخزن عمومی fork شده ی خود را کپی کند. آنها می توانند این کار را با دستور Git clone انجام دهند. با فرض استفاده از GitHub برای میزبانی این مخازن، توسعه دهندگان یک پروژه باید حساب GitHub خود را داشته باشند و آنها باید نسخه Fork شده مخزن خود را با استفاده از دستور زیر کپی کنند:
افزودن ریموت
در حالی که سایر گردش کارهای Git تنها از ریموت اصلی که به مخزن مرکزی اشاره دارد استفاده می کنند، گردش کارForking به دو ریموت نیاز دارد - یکی برای مخزن رسمی و دیگری برای مخزن سمت سرور شخصی توسعه دهنده. در حالی که می توانید این ریموت ها را هر جا که خواستید فراخوانی کنید، یک قرارداد معمول این است که از ریموت اصلی برای مخزن fork خود استفاده کنید (به طور خودکار با اجرای Git clone ایجاد می شود) و از ریموت upstream (به معنی بالادست است و برای اشاره به مخزن اصلی و رسمی در Git استفاده می شود) برای مخزن رسمی.
git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.gitبا استفاده از دستور بالا می توانید ریموت upstream برای خود ایجاد کنید. این کار به شما این امکان را می دهد که با پیشرفت پروژه رسمی، مخزن محلی خود را به راحتی به روز نگه دارید. توجه داشته باشید که اگر مخزن upstream شما احراز هویت را فعال کرده باشد (به عنوان مثال منبع باز نباشد)، کاربر باید هنگام pull کردن یا clone کردن از پایگاه کد رسمی، رمز عبور معتبری را ارائه دهد.
کار کردن در یک شاخه: ایجاد و push کردن تغییرات
مانند سایر گردش های کار Git در نسخه ی محلی توسعه دهنده از مخزن fork شده، توسعه دهندگان می توانند شاخه هایی درست کنند، کد را ویرایش کنند و تغییرات را commit کنند:
git checkout -b some-feature #Edit some code
git commit -a -m “Add first draft of some feature”تمام تغییرات آنها کاملاً خصوصی خواهد بود تا زمانی که آن را به مخزن عمومی خود push کنند. اگر پروژه ی رسمی پیشرفت یا تغییری کرده باشد، آنها می توانند با Git pull به commit های جدید دسترسی پیدا کنند:
git pull upstream masterتوسعه دهندگان برای اینکه به هنگام pull کردن دچار ناسازگازی نشوند باید در یک شاخه feature اختصاصی کار کنند تا این امر منجر به merge سریع شود.
ایجاد یک Pull Request
برای این کار باید ریموت اصلی از قبل تنظیم شود، بنابراین تمام کاری که باید انجام دهد اجرای دستور زیر است:
git push origin feature-branchاختلاف گردش کار forking از سایر گردش کارها به این دلیل است که در این گردش کار، ریموت اصلی، به مخزن شخصی سمت سرور توسعه دهنده اشاره می کند، نه پایگاه کد اصلی.
دوم، باید به نگهدارنده ی پروژه اطلاع دهد که می خواهد feature خود را در پایگاه کد رسمی merge کند.
GitHub یک دکمه "Pull request" را در اختیار شما قرار می دهد که منجر به ایجاد یک فرم می شود و از شما می خواهد مشخص کنید کدام شاخه را می خواهید در مخزن رسمی merge کنید. به طور معمول، شما می خواهید شاخه ی feature خود را در شاخه master ریموت upstream، merge کنید.
نتیجه
به طور خلاصه، گردش کار Forking معمولاً در پروژه های منبع باز عمومی مورد استفاده قرار می گیرد. Forking یک عملیات git clone است که روی یک سرور کپی شده از مخزن یک پروژه اجرا می شود. گردش کار Forking معمولا همراه با یکی از سرویس های میزبانی Git مانند GitHub استفاده می شود. یک مثال سطح بالا از گردش کار Forking این است:
1. شما می خواهید در یک کتابخانه ی منبع باز میزبانی شده درآدرس زیر مشارکت کنید و
github.com/userA/open-project
2. با استفاده از github، یک fork از مخزنی به آدرس زیر ایجاد می کنید.
github.com /YourName/open-project
3. در سیستم محلی خود، git clone را با آدرس زیر اجرا می کنید تا یک نسخه ی محلی از مخزن را دریافت کنید.
github.com /YourName/open-project
4. یک شاخه ی feature جدید در نسخه محلی خود ایجاد می کنید.
5. بر روی feature جدید کار می کنید تا تکمیل شود و دستور git commit را برای ذخیره ی تغییرات انجام شده اجرا می کنید.
6. شاخه ی feature جدید را به ریموت مخزن fork شده خود push می کنید.
7. با استفاده از github درخواست pull را برای شاخه ی جدید به نسخه ی اصلی درآدرس زیر ارائه می دهید.
github.com/userA/open-project
گردش کار Forking به یک نگهدارنده ی پروژه کمک می کند تا مخزن مشارکت های مربوط به هر توسعه دهنده ای را باز کند بدون اینکه به صورت دستی تنظیمات مجوز را برای هر مشارکت کننده شخصی مدیریت کند. این کار گردش کاری که بیشتر شبیه به سبک "pull" است را به نگه دارنده می دهد. گردش کار Forking که معمولاً در پروژه های منبع باز استفاده می شود، می تواند در گردش کار مشاغل خصوصی نیز اعمال شود تا کنترل معتبری بر آنچه که در نسخه ی ارائه شونده merge می شود، داشت. این کار می تواند در تیم هایی که Deploy Managers یا چرخه های انتشار دقیق دارند مفید باشد.