مخزن GitHub را جابه‌جا کنید؛ GitHub Pages با Redirect نمی‌آید

برای انتقال مخزن GitHub به سازمان، نخست دسترسی خود و آزاد بودن نام مخزن در مقصد را بررسی کنید و سپس گزینه Transfer را در تنظیمات مخزن بزنید. راهنمای انتقال GitHub می‌گوید Issueها، Pull Requestها و Forkها همراه مخزن می‌مانند و لینک‌های نشانی قدیمی مخزن به محل تازه هدایت می‌شوند؛ این هدایت شامل نشانی GitHub Pages نیست.

پس از انتقال، remote نسخه‌های محلی را به نشانی سازمان تغییر دهید. سپس لینک‌های مخزن و سایت Pages را جداگانه باز کنید و دسترسی افراد و اتصال Packageها را در مقصد بررسی کنید؛ سالم بودن لینک مخزن به‌تنهایی وضعیت این بخش‌ها را نشان نمی‌دهد.

پیش از انتقال، نام و مجوزها را مشخص کنید

آغازکننده انتقال باید دسترسی مدیر مخزن را داشته باشد. انتقال به سازمان مقصد به اجازه ساخت مخزن در آن سازمان نیاز دارد؛ اگر مبدأ نیز یک سازمان است، سیاست آن باید اجازه خروج مخزن را بدهد. پیش از شروع، این دو مجوز را با مدیران سازمان‌ها هماهنگ کنید تا انتقال در مرحله انتخاب مالک تازه متوقف نشود.

سازمان مقصد نباید مخزنی هم‌نام یا Forkی از همان شبکه با نام موردنظر داشته باشد. اگر نام اشغال است، درباره تغییر نام با مالک مقصد تصمیم بگیرید؛ تغییر نام مخزن هنگام انتقال به مالک بودن در سازمان مقصد وابسته است. همچنین مخزنی که به‌تنهایی Fork یک شبکه خصوصی بالادستی است، قابل انتقال نیست.

برای مخزن خصوصی، طرح حساب مقصد را هم بررسی کنید. انتقال آن به حساب یا سازمانی در طرح GitHub Free می‌تواند دسترسی به قابلیت‌هایی مانند شاخه‌های محافظت‌شده و GitHub Pages را از بین ببرد. اگر سایت Pages دامنه اختصاصی دارد، تنظیمات دامنه و رکوردهای DNS نیز باید پیش از انتقال بررسی شوند، به‌ویژه وقتی سایت از مخزن خصوصی منتشر شده است.

اگر خودتان اجازه لازم برای ساخت مخزن در سازمان مقصد را ندارید، انتقال می‌تواند با همکاری فردی دارای دسترسی مناسب انجام شود. در رویه Google Open Source، برای چنین وضعی انتقال چندمرحله‌ای از طریق مالک GitHub آن سازمان پیش‌بینی شده است. این مسیر به هماهنگی با متولی مقصد وابسته است؛ نام حساب واسطه و ترتیب کار را باید همان سازمان تعیین کند.

انتقال را در تنظیمات مخزن انجام دهید

1. صفحه مخزن مبدأ را باز کنید و وارد Settings شوید.
2. در پایین صفحه، از بخش Danger Zone گزینه Transfer را انتخاب کنید.
3. سازمان مقصد را از فهرست انتخاب کنید یا نام مالک تازه را وارد کنید. اگر قرار است نام مخزن عوض شود، آن را در همین مرحله مشخص کنید.
4. هشدارهای مربوط به انتقال و امکانات طرح مقصد را بخوانید، نام مخزن را برای تأیید وارد کنید و عملیات را نهایی کنید.

بعد از انتقال، مخزن را زیر حساب سازمان مقصد باز کنید و نام، محتوا و تنظیمات اصلی آن را ببینید. مالک تازه بلافاصله می‌تواند محتوا، Issueها، Pull Requestها، انتشارها و تنظیمات مخزن را مدیریت کند. اگر پروژه به دسترسی تیم‌های مشخص وابسته است، فقط ظاهر شدن مخزن در سازمان را نشانه آماده بودن دسترسی‌ها ندانید.

دارایی‌ها و مسئولیت Issueها را بازبینی کنید

Issueها، Pull Requestها، Wiki، ستاره‌ها و Watcherها همراه مخزن منتقل می‌شوند. رابطه مخزن با Fork بالادستی و Forkهای ساخته‌شده از آن نیز حفظ می‌شود. اطلاعات commitها و مشارکت‌ها باقی می‌ماند و اگر مخزن از Git LFS استفاده می‌کند، اشیای آن در پس‌زمینه جابه‌جا می‌شوند؛ برای حجم زیاد، این بخش ممکن است زمان ببرد.

Webhookها، secretها و deploy keyهای موجود به مخزن منتقل‌شده متصل می‌مانند. همکاران قبلی نیز باقی می‌مانند و مالک پیشین به‌عنوان همکار اضافه می‌شود، اما تنظیمات پیش‌فرض مجوز مخزن و عضویت سازمان مقصد اعمال خواهد شد. نقش تیم‌ها و دسترسی افرادی را که باید کد را نگه دارند یا Issueها را مدیریت کنند، در مقصد بازبینی کنید.

خود Issueها باقی می‌مانند، اما مسئول تعیین‌شده برای هرکدام در همه مسیرهای انتقال یکسان حفظ نمی‌شود. هنگام انتقال از حساب شخصی به سازمان، انتساب Issue به اعضای سازمان مقصد می‌ماند و انتساب به دیگران پاک می‌شود. اگر کار تیم بر پایه assigneeها تقسیم شده است، پیش از انتقال Issueهای مربوط را مشخص کنید و بعد از انتقال موارد بی‌مسئول را دوباره تخصیص دهید.

Remote و نشانی قدیمی مخزن را کنترل کنید

لینک‌های محل قبلی مخزن و عملیات Git مانند clone، fetch و push به نشانی جدید هدایت می‌شوند. بااین‌حال، remote نسخه‌های محلی را مستقیم به نشانی تازه تغییر دهید تا همکاران و ابزارها به مسیر قدیمی متکی نمانند. در پوشه نسخه محلی، با git remote -v نشانی فعلی را ببینید، سپس git remote set-url origin NEW_URL را اجرا کنید؛ NEW_URL را با نشانی Clone مخزن در سازمان مقصد جایگزین کنید و خروجی remote را دوباره ببینید.

یک لینک قدیمی به خود مخزن و لینک‌هایی به یک Issue و یک Pull Request را باز کنید تا مقصد هدایت را ببینید. مسیر قدیمی را برای مخزن یا Fork تازه دوباره به کار نگیرید: ساخت مخزن یا Fork در آن محل، هدایت‌های مخزن منتقل‌شده را برای همیشه حذف می‌کند. اگر این لینک‌ها در مستندات یا بیرون از GitHub منتشر شده‌اند، حفظ نام قدیمی بخشی از حفظ دسترسی خوانندگان است.

برای Pages و Packageها بررسی جداگانه بگذارید

نشانی GitHub Pages همراه هدایت نشانی مخزن منتقل نمی‌شود. راهنمای انتقال W3C برای حفظ لینک‌های قدیمی Pages، ایجاد یک صفحه هدایت در سایت متعلق به مالک پیشین را پیشنهاد می‌کند. در نمونه آن، صفحه‌ای در مسیر قدیمی ساخته می‌شود که بازدیدکننده را به نشانی سایت زیر سازمان مقصد می‌برد؛ این صفحه باید جداگانه ایجاد و نگهداری شود.

اگر از این روش استفاده می‌کنید، نشانی قدیمی، نشانی تازه و لینک‌های واقعی به صفحه‌های داخلی را باز کنید. نمونه W3C بخش پس از علامت # را به مقصد می‌برد، اما برای مسیرهای داخلی دیگر باید هدایت متناسب با ساختار سایت خود را طراحی کنید. اگر سایت دامنه اختصاصی دارد، رسیدن دامنه به سایت موردنظر و وضعیت DNS را نیز همراه همین آزمون بررسی کنید.

Packageهای وابسته به مخزن هم نتیجه یکسانی در همه registryها ندارند: ممکن است منتقل شوند یا پیوندشان با مخزن از دست برود. پس از انتقال، صفحه هر Package، اتصال آن به مخزن تازه و دسترسی لازم برای انتشار بعدی را بررسی کنید. با انجام این کنترل‌ها، وضعیت کد، گفت‌وگوهای پروژه، نشانی سایت و بسته‌های منتشرشده هرکدام روشن خواهد بود.

بیشتر بخوانید:

• آنبوردینگ دورکار با فایل تمام نمی‌شود؛ دوست همراه و نخستین کار لازم‌اند
• GitHub Codespaces یا Ona؛ ساعت ارزان همیشه صورت‌حساب ارزان نمی‌سازد
• حساب Telegram را امن کنید؛ نشست ناشناس را پیش از تغییر رمز ببندید