گردش کار جعل

گردش کار Forking اساساً با سایر گردش کار GIT متفاوت است. به جای استفاده از یک مخزن سمت سرور واحد برای عمل به عنوان پایگاه "مرکزی" ، به هر توسعه دهنده مخزن سمت سرور خود می دهد. این بدان معناست که هر یک از مشارکت کنندگان یک مخزن GIT ندارند بلکه دو مخزن GIT دارند: یک محلی خصوصی و یک سرور عمومی. گردش کار Forking اغلب در پروژه های منبع باز عمومی مشاهده می شود.

مهمترین مزیت گردش کار Forking این است که می توان بدون نیاز همه به یک مخزن مرکزی واحد ، کمک کرد. توسعه دهندگان به مخازن سمت سرور خود فشار می آورند و فقط نگهدارنده پروژه می تواند به مخزن رسمی فشار بیاورد. این امر به نگهبان این امکان را می دهد تا تعهدات را از هر توسعه دهنده بپذیرد بدون اینکه به آنها دسترسی به پایگاه رسمی باشد.

گردش کار Forking به طور معمول از یک مدل انشعاب بر اساس گردش کار GitFlow پیروی می کند. این بدان معنی است که شاخه های کامل ویژگی برای ادغام در مخزن نگهدارنده پروژه اصلی هدف قرار می گیرند. نتیجه یک گردش کار توزیع شده است که روشی انعطاف پذیر برای تیم های بزرگ و ارگانیک (از جمله اشخاص ثالث غیرقابل اعتماد) برای همکاری ایمن فراهم می کند. این همچنین آن را به یک گردش کار ایده آل برای پروژه های منبع باز تبدیل می کند.

چگونه کار می کند

مانند سایر گردش کار GIT ، گردش کار Forking با یک مخزن رسمی رسمی که در یک سرور ذخیره می شود ، آغاز می شود. اما هنگامی که یک توسعه دهنده جدید می خواهد کار خود را روی این پروژه شروع کند ، آنها به طور مستقیم مخزن رسمی را کلون نمی کنند.

در عوض ، آنها مخزن رسمی را برای ایجاد یک نسخه از آن در سرور چنگ می زنند. این نسخه جدید به عنوان مخزن عمومی شخصی آنها خدمت می کند - به سایر توسعه دهندگان اجازه نمی دهند به آن فشار بیاورند ، اما می توانند تغییراتی را از آن بکشند (خواهیم دید که چرا این در یک لحظه مهم است). پس از ایجاد کپی سمت سرور خود ، توسعه دهنده یک کلون GIT را انجام می دهد تا یک نسخه از آن را بر روی دستگاه محلی خود دریافت کند. این مانند محیط توسعه خصوصی آنها ، دقیقاً مانند سایر گردش کار است.

هنگامی که آنها آماده انتشار یک تعهد محلی هستند ، آنها تعهد را به مخزن عمومی خود سوق می دهند - نه رسمی. سپس ، آنها یک درخواست کشش را به مخزن اصلی ارائه می دهند ، که به نگهدارنده پروژه می دهد بداند که به روزرسانی آماده ادغام است. درخواست کشش همچنین در صورت بروز مشکلاتی با کد مشارکت شده ، به عنوان یک موضوع بحث مناسب عمل می کند. در زیر نمونه گام به گام این گردش کار است.

1. یک توسعه دهنده "Forks" یک "رسمی" مخزن سمت سرور. این کپی سمت سرور خود را ایجاد می کند.
2. نسخه جدید سرور به سیستم محلی آنها کلون شده است.
3. یک مسیر از راه دور git برای مخزن "رسمی" به کلون محلی اضافه می شود.
4. یک شاخه ویژگی محلی جدید ایجاد شده است.
5. توسعه دهنده در شاخه جدید تغییراتی ایجاد می کند.
6. تعهدات جدید برای تغییرات ایجاد شده است.
7. شعبه به کپی سمت سرور خود توسعه دهنده سوق می یابد.
8. توسعه دهنده درخواست کشش را از شعبه جدید به مخزن "رسمی" باز می کند.
9. درخواست کشش برای ادغام تأیید می شود و در مخزن اصلی سرور ادغام می شود

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

درک این نکته مهم است که مفهوم یک مخزن "رسمی" در گردش کار Forking صرفاً یک کنوانسیون است. در حقیقت ، تنها چیزی که مخزن رسمی را به این مقام رسمی می کند این است که این مخزن عمومی نگهدارنده پروژه است.

Forking vs Cloning

توجه به این نکته حائز اهمیت است که مخازن "چنگال" و "چنگال" عملیات ویژه ای نیستند. مخازن Forked با استفاده از دستور استاندارد Git Clone ایجاد می شوند. مخازن Forked به طور کلی "کلون های سمت سرور" هستند و معمولاً توسط یک سرویس GIT شخص ثالث مانند Bitbucket اداره و میزبانی می شوند. هیچ دستور git منحصر به فرد برای ایجاد مخازن چنگال وجود ندارد. یک عمل کلون در اصل یک نسخه از مخزن و تاریخچه آن است.

انشعاب در گردش کار چنگال

همه این مخازن عمومی شخصی واقعاً فقط یک روش مناسب برای به اشتراک گذاشتن شاخه ها با سایر توسعه دهندگان هستند. همه افراد هنوز هم باید از شاخه ها برای جداسازی ویژگی های فردی استفاده کنند ، دقیقاً مانند گردش کار شاخه ویژگی و گردش کار GitFlow. تنها تفاوت این است که چگونه این شاخه ها به اشتراک می گذارند. در گردش کار Forking ، آنها به مخزن محلی توسعه دهنده دیگر کشیده می شوند ، در حالی که در شعبه ویژگی و گردش کار GitFlow آنها را به مخزن رسمی سوق می دهند.

یک مخزن را چنگ بزنید

همه توسعه دهندگان جدید پروژه Forking Workflow باید مخزن رسمی را فورک کنند. همانطور که قبلاً گفته شد، فورکینگ فقط یک عملیات کلون git استاندارد است. انجام این کار با SSH در سرور و اجرای git clone برای کپی کردن آن در مکان دیگری در سرور امکان پذیر است. سرویس های میزبانی محبوب Git مانند Bitbucket، ویژگی های فورکینگ مخزن را ارائه می کنند که این مرحله را خودکار می کند.

چنگال خود را کلون کنید

در مرحله بعد، هر توسعه دهنده باید مخزن فورک شده عمومی خود را شبیه سازی کند. آنها می توانند این کار را با دستور git clone آشنا انجام دهند.

با فرض استفاده از Bitbucket برای میزبانی این مخازن، توسعه دهندگان در یک پروژه باید حساب Bitbucket خود را داشته باشند و باید کپی فورک شده خود از مخزن را با استفاده از موارد زیر شبیه سازی کنند:

اضافه کردن یک کنترل از راه دور

در حالی که سایر گردش های کاری Git از یک کنترل از راه دور مبدأ واحد استفاده می کنند که به مخزن مرکزی اشاره می کند، Forking Workflow به دو ریموت نیاز دارد - یکی برای مخزن رسمی و دیگری برای مخزن شخصی سمت سرور توسعه دهنده. در حالی که می توانید این ریموت ها را هر چیزی که می خواهید صدا بزنید، یک قرارداد رایج این است که از مبدا به عنوان ریموت برای مخزن فورکی خود استفاده کنید (این ریموت به طور خودکار هنگام اجرای git clone ایجاد می شود) و از بالادست برای مخزن رسمی.

باید خودتان با استفاده از دستور بالا ریموت بالادستی ایجاد کنید. این به شما این امکان را می دهد که به راحتی با پیشرفت پروژه رسمی، مخزن محلی خود را به روز نگه دارید. توجه داشته باشید که اگر مخزن بالادستی شما احراز هویت را فعال کرده باشد (به عنوان مثال، منبع باز نیست)، باید یک نام کاربری ارائه دهید، مانند:

این امر مستلزم آن است که کاربران یک رمز عبور معتبر قبل از شبیه سازی یا بیرون کشیدن از پایگاه کد رسمی ارائه کنند.

کار در یک شعبه: ایجاد و فشار دادن به تغییرات

در کپی محلی توسعه دهنده از مخزن فورک شده، آنها می توانند کد را ویرایش کنند، تغییرات را انجام دهند، و شعبه هایی ایجاد کنند، درست مانند سایر گردش های کاری Git:

همه تغییرات آنها کاملاً خصوصی خواهد بود تا زمانی که آنها را به مخزن عمومی خود منتقل کنند. و اگر پروژه رسمی جلو رفته باشد، می توانند با git pull به commit های جدید دسترسی داشته باشند:

از آنجایی که توسعه دهندگان باید در یک شاخه ویژگی اختصاصی کار کنند، این امر معمولاً منجر به ادغام سریع به جلو می شود.

ایجاد یک درخواست کشش

هنگامی که یک توسعه دهنده آماده است تا ویژگی جدید خود را به اشتراک بگذارد، باید دو کار را انجام دهد. اول، آنها باید مشارکت خود را با فشار دادن آن به مخزن عمومی خود در دسترس سایر توسعه دهندگان قرار دهند. ریموت اصلی آنها باید قبلاً تنظیم شده باشد، بنابراین تمام کاری که باید انجام دهند این است که:

این امر از سایر گردش کار ها به این دلیل که از راه دور مبدا به مخزن سمت سرور شخصی توسعه دهنده اشاره می کند ، نه قسمت اصلی کد.

دوم ، آنها باید به نگهدارنده پروژه اطلاع دهند که می خواهند ویژگی خود را در پایگاه رسمی کد ادغام کنند. Bitbucket دکمه "درخواست کشش" را فراهم می کند که منجر به فرم می شود و از شما می خواهد مشخص کنید کدام شاخه را می خواهید در مخزن رسمی ادغام کنید. به طور معمول ، شما می خواهید شاخه ویژگی خود را در شاخه اصلی از راه دور بالادست ادغام کنید.

خلاصه

برای یادآوری ، گردش کار Forking معمولاً در پروژه های منبع باز عمومی مورد استفاده قرار می گیرد. Forking یک عملیات کلون GIT است که بر روی کپی سرور یک repo پروژه اجرا شده است. یک گردش کار چنگال اغلب در رابطه با سرویس میزبانی GIT مانند Bitbucket استفاده می شود. نمونه ای از سطح بالا از گردش کار جعلی:

1. شما می خواهید به یک کتابخانه منبع باز که در bitbucket. org/usera/open-project میزبان است ، مشارکت کنید
2. با استفاده از Bitbucket شما یک چنگال از repo به Bitbucket. org/youame/open-project ایجاد می کنید
3. در سیستم محلی خود شما کلون Git را در https://bitbucket. org/youame/open-project اجرا می کنید تا یک نسخه محلی از repo دریافت کنید
4. شما یک شاخه ویژگی جدید در repo محلی خود ایجاد می کنید
5. کار برای تکمیل ویژگی جدید انجام می شود و Git Commit برای ذخیره تغییرات اجرا می شود
6. سپس شاخه ویژگی جدید را به repo از راه دور چنگال خود فشار می دهید
7. با استفاده از Bitbucket ، شما یک درخواست کشش برای شعبه جدید در برابر repo اصلی در bitbucket. org/usera/open-project باز می کنید

گردش کار Forking به نگهدارنده یک پروژه کمک می کند تا بدون نیاز به مدیریت دستی تنظیمات مجوز برای هر یک از مشارکت کنندگان ، مخزن را برای کمک به هر توسعه دهنده باز کند. این امر به نگهدارنده بیشتر گردش کار "کشش" می دهد. معمولاً در پروژه های منبع باز استفاده می شود ، گردش کار Forking نیز می تواند در گردش کار تجاری خصوصی اعمال شود تا کنترل معتبرتر بر آنچه در یک نسخه ادغام شده است ، انجام شود. این می تواند در تیم هایی که مدیران مستقر یا چرخه آزادی دقیق دارند ، مفید باشد.

مطمئن نیستید که گردش کار برای شما مناسب است؟صفحه جامع مقایسه گردش کار GIT ما را بررسی کنید.