Repo Forked Git خود را با تغییراتی از The Original Upstream Repo به روز نگه دارید

من چندین بار در ایمیل ها این را برای چند نفر توضیح داده ام. من واقعاً یک URL می خواهم که افراد را به آن نشان دهد تا بتوانم آنها را آنجا نشان دهم، بنابراین در اینجا یک پست وبلاگ وجود دارد که آن را نشان می دهد. TL; DR سناریو این است که شما می خواهید در یک پروژه عمومی در یک مخزن git (repo) مشارکت کنید. رایج ترین و بهترین راه برای انجام این کار این است که مخزن را فورک کنید تا نسخه خود را داشته باشید. سپس تغییرات خود را در نسخه خود (که معمولاً مخزن انشعابی نامیده می شود) که کاملاً مستقل از مخزن اصلی است (که معمولاً upstream نامیده می شود) ایجاد می کنید. هنگامی که تغییرات خود را انجام دادید، آنها را در یک درخواست کشش به مخزن اصلی ارسال می کنید که اساساً از صاحب مخزن اصلی درخواست می کند که تغییرات شما را با کشیدن کد شما از مخزن انشعاباتی شما به مخزن اصلی خود انجام دهد. ساده به نظر می رسد، با این تفاوت که یک سناریوی کلیدی وجود دارد که باید در نظر بگیرید: چه اتفاقی می افتد که مخزن بالادستی دارای تغییراتی است که بین زمانی که برای اولین بار آن را فورک کردید و زمانی که درخواست کشش را ارسال کردید رخ می دهد؟شاید این تغییرات کد با تغییراتی که شما ایجاد کرده اید در تضاد باشد. شما برای اطمینان از کدی که به آن ارسال می کنید مسئول هستید.

من چندین بار در ایمیل ها این را برای چند نفر توضیح داده ام. من واقعاً یک URL می خواهم که افراد را به آن نشان دهد تا بتوانم آنها را به آنجا نشان دهم، بنابراین در اینجا یک پست وبلاگ وجود دارد که آن را نشان می دهد.

سناریو این است که شما می خواهید به یک پروژه عمومی در یک مخزن git (repo) کمک کنید. رایج ترین و بهترین راه برای انجام این کار این است که مخزن را فورک کنید تا نسخه خود را داشته باشید. سپس تغییرات خود را در نسخه خود (که معمولاً مخزن فورکی نامیده می شود) که کاملاً مستقل از مخزن اصلی است (که معمولاً به آن upstream گفته می شود) ایجاد می کنید. هنگامی که تغییرات خود را انجام دادید، آنها را در یک درخواست کششی به مخزن اصلی ارسال می کنید که اساساً از صاحب مخزن اصلی درخواست می کند که تغییرات شما را با کشیدن کد شما از مخزن فورک شده شما به مخزن اصلی خود انجام دهد.

ساده به نظر می رسد، با این تفاوت که یک سناریوی کلیدی وجود دارد که باید در نظر بگیرید: چه اتفاقی می افتد که مخزن بالادستی دارای تغییراتی است که بین زمانی که برای اولین بار آن را فورک کردید و زمانی که درخواست کشش را ارسال کردید، رخ می دهد؟شاید این تغییرات کد با تغییراتی که شما ایجاد کرده اید در تضاد باشد. شما برای اطمینان از کدی که به کار مخزن اصلی ارسال می کنید، مسئول هستید. شما چیزهایی را که خراب می شود برای صاحبش ارسال نمی کنید زیرا آنها آن را نمی پذیرند.

کاری که شما باید انجام دهید این است که repo چنگال خود را در همگام سازی با repo اصلی نگه دارید. این توسط بسیاری از نام ها و عبارات مانند نگه داشتن چنگال خود در همگام سازی با بالادست انجام می شود. در این پست من توضیح و نشان می دهم که چگونه می توان آن را همگام سازی کرد.

GitHub دو مقاله دارد که دستورات CLI را نشان می دهد که می توانید برای انجام این همه مواردی که در اینجا توضیح خواهم داد ، به Git بپردازید:

من از اصطلاحات آنها استفاده می کنم زیرا آنها اصطلاحات عموماً پذیرفته شده هستند ، اما تصاویر مورد استفاده من از ابزار کنترل منبع مورد استفاده من و ترجیح می دهم: SmartGit. من همچنین از repo برای پارچه UI Office استفاده می کنم.

شروع - Forking & Cloning repo

من می خواهم فرض کنم که شما قبلاً چنگال اصلی را ایجاد کرده اید. شما این کار را با رفتن به هرگونه repo در GitHub انجام می دهید و روی Bork Badge در گوشه بالا سمت راست کلیک می کنید. این یک نسخه از repo اصلی را در حساب GitHub شما ایجاد می کند که به نظر می رسد:

توجه کنید که دقیقاً زیر repo خود نشان می دهد که repo اصلی کجاست. در این تصویر ما نسخه شما را (که به عنوان Andrewconnell / Office-Ui-Fabric نشان داده شده است) Fork و اصلی (که به عنوان Assevedev / Office-Ui-Fabric) بالادست را نشان می دهیم ، بالادست می نامیم.

برای انجام هر کار با این کار ، باید چنگال خود را به دستگاه محلی خود کلون کنید که در آن دقیقاً مانند هر repo دیگر کار می کنید. ما به این نسخه از repo در دستگاه شما repo محلی مراجعه می کنیم.

راه دور را در repo بالادست تنظیم کنید

هنگامی که چنگال خود را به دستگاه محلی خود کلون کردید ، یک repo از راه دور به نام Origin خواهید داشت. این به repo چنگال شما در حساب GitHub خود اشاره دارد. این کار به طور پیش فرض تنظیم می شود وقتی که یک repo را کلون می کنید.

بنابراین ، برای مرور ، در رایانه محلی خود یک repo محلی دارید که در آن کار خود را انجام می دهید. این یک منشاء از راه دور است که به چنگال شما از repo اصلی بالادست اشاره دارد. هر دو REPO های چنگال و بالادست در Github زندگی می کنند ، نه در دستگاه محلی شما.

اما اگر بعد از ایجاد چنگال ، همه چیز در repo بالادست تغییر کند؟شما باید این تغییرات را به چنگال خود وارد کنید. از آنجا که شما هرگز واقعاً هیچ پیشرفتی در GitHub انجام نداده اید ، بلکه روی دستگاه خود کار می کنید و تغییرات را به GitHub فشار می دهید ، باید این تغییرات را از بالادست به repo محلی خود بدست آورید.

برای انجام این کار ، شما باید یک راه دور دوم را در دستگاه محلی خود کرت کنید. ما این را بالادست می نامیم. بر اساس ابزاری که از آن استفاده می کنید یا اگر از خط فرمان استفاده می کنید ، UX های مختلف زیادی برای این کار وجود دارد. کاری که شما می خواهید انجام دهید این است که URL را برای repo اصلی (با نام مستعار: بالادست) دریافت کنید - در این حالت این URL برای repo پارچه UI Office است. اکنون یک ریموت جدید به نام بالادست با URL repo Git اصلی ایجاد کنید.

بیایید ببینیم کجا هستیم. اگر Command Git Branc h-a را از خط فرمان اجرا کنید ، لیستی از تمام شاخه های مورد نظر خود را مشاهده خواهید کرد ، از جمله مواردی که برای راه دور وجود دارد:

اگر Git Remot e-v را اجرا کنید ، لیستی از راه دور و URL های مربوطه را که به آنها اشاره می کنند مشاهده خواهید کرد.

در SmartGit این چیزی است که من می بینم & mldr ؛این سازمان خوب از همه چیز است.

در این مرحله ، همه ما ، هم در GitHub و هم در دستگاه محلی خود ، برای مشارکت در پروژه عمومی تنظیم شده ایم.

همگام سازی چنگال خود را

از آنجا که در ابتدا چنگال را ایجاد کرده اید ، repo بالادست تغییراتی در آن انجام داده است. قبل از اینکه بتوانید تغییرات خود را به repo بالادست ارسال کنید ، باید آخرین نسخه از repo بالادست را دریافت کنید تا اطمینان حاصل شود که هنگام ارسال درخواست PULL (PR) به repo بالادست ، تغییرات شما را نمی شکند. اگر این کار را انجام دهند ، می توانید اطمینان حاصل کنید که فرصت خوبی وجود دارد که روابط عمومی شما رد شود - ایده این بود که شما به پروژه کمک کنید و مشارکت کنید ، نه چیزها را بدتر کنید!

از کجا می دانید که از همگام سازی خارج شده اید؟آسان & mldr ؛به چنگال خود در GitHub & mldr بروید. اگر می گوید شما در پشت repo بالادست هستید ، پس از همگام سازی خارج نمی شوید. این را می توانید از چنگال من در زیر مشاهده کنید. این نشان می دهد که از زمان آخرین بار (یا همگام سازی) از بالادست 17 تعهد وجود داشته است:

• تغییرات را از بالادست/استاد بارگیری کنید
• تغییرات را از بالادست/استاد به محلی/استاد خود ادغام کنید
• تغییرات موجود در محلی/استاد خود را در شعبه محلی/شماره 123 خود ادغام کنید
• به صورت اختیاری تغییرات را از ادغام در محلی/استاد به Origin/Master فشار دهید تا از شر این شعبه 17 تعهد در پشت Assev: پیام اصلی در تصویر بالا استفاده کنید

شما می خواهید چنگال شما با repo بالادست یکسان باشد + شامل تغییرات شما می شود. بنابراین چگونه می توانم این را برطرف کنم؟Github مقاله خوبی دارد که این موضوع را توضیح می دهد ، Github: همگام سازی چنگال ، اما اگرچه چیزهای خط فرمان قدرتمند است ، تجسم آن دشوار است.

کاری که من در SmartGit انجام می دهم ، راست روی بالادست از راه دور در لیست شاخه های من کلیک کنید و کشش را انتخاب کنید تا تمام تغییرات را از بالادست به پایین دستگاه محلی من بدست آورد.

اکنون می خواهم تغییرات را از شاخه بالادست به شاخه محلی خود ادغام کنم. وقتی ابزار ادغام را در SmartGit مطرح می کنم ، ابتدا مطمئن می شوم که تمام شاخه هایی را که علاقه مند به انتخاب شده ام ، دارم. در این حالت ، من حداقل به شاخه های زیر علاقه مندم:

• محلی/استاد
• مبدا/استاد
• از راه دور/استاد

این چیزی است که من می بینم:

این چه چیزی به من نشان می دهد؟خط برجسته آبی نشان می دهد که این هم Origin/Master است و هم در جایی که محلی/استاد فعلی من است (که توسط پیکان سبز که نشان می دهد سر من کجاست). همچنین این نشان می دهد که پیش از من ، 17 متعهد از من ، جایی است که من در بالادست/استاد پیدا خواهم کرد.

هدف من چیست؟من می خواهم همه 17 مورد از این نظرات را در محلی/استاد خود داشته باشم! به عبارت دیگر ، اگر این خط برتر Origin/Master و بالادست/استاد را در کنار یکدیگر نشان می دهد ، بازی را برنده می شوم. این بدان معناست که آنها هر دو در یک سطح هستند و گرفتار شده اند. خوب & mldr ؛در واقع من آنها را در محلی/شماره 123 می خواهم ، اما بعداً این اتفاق می افتد.

بنابراین کاری که من انجام می دهم این است که خط را با بالادست/استاد روی آن انتخاب کنید و بر روی دکمه ایجاد ادغام بر روی دکمه Create کلیک کنید و در صورت درخواست ، یک ادغام سریع را انتخاب می کنم. آنچه این کار را انجام می دهد این است که اساساً می گوید همه آن تغییرات را در شعبه محلی من اعمال کنید & mldr ؛یا بهتر از این ، فقط سریع مرا به جایی که در بالادست هستند ، سریع جلو کنید.

در این زمان من تأیید می کنم که کد من هنوز به صورت محلی کار می کند & mldr ؛اگر اینگونه نباشد به این دلیل است که من احتمالاً چیزی را تغییر داده ام که باید به آن بپردازم.

سپس همان فرآیند ادغام را تکرار می کنم اما از محلی/استاد به محلی/شماره 123 ادغام می شوم.

و سرانجام ، من تمام تغییرات خود را در شاخه های محلی خود به منشأ خود فشار می دهم ، بنابراین یک پیام کوچک خوب دریافت می کنم که می گوید حتی با بالادست هستم!

تفکرات فراق

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

چند بار باید همگام سازی کنید؟خوب این بستگی به میزان فعالیت در بالادست دارد. من معمولاً این کار را هر روز یا هر روز دیگر انجام می دهم & mldr ؛این مانند شستن دستان شما است. استدلال در مورد انجام این کار بیش از حد دشوار است ، اما استدلال در مورد عدم انجام آن به اندازه کافی آسان است.

اوه آره & mldr ؛و بعد از پذیرش یکی از روابط عمومی شما ، به یاد داشته باشید & mldr ؛این یک تغییر در بالادست است. فقط به این دلیل که آن را درست کرده اید ، باید مطمئن شوید که به نسخه محلی خود اضافه می شود تا گردش کار باید چیزی شبیه به این باشد: