Що насправді змінює перенесення
Перенесення репозиторію GitHub переміщує репозиторій до іншого акаунта власника. Це не та сама операція, що зміна імені користувача профілю. Зміна імені користувача змінює публічну ідентичність акаунта та URL-адреси, побудовані на ній; перенесення репозиторію змінює, кому належить цей один проєкт. Якщо ваша мета — чистіше ім’я профілю, а не передача проєкту комусь іншому, наведені нижче кроки перенесення — не той інструмент.
Ця різниця важлива для планування. Щойно акаунт початкового власника закрито, ніхто не зможе увійти, щоб прийняти запрошення, підтвердити подальші дії чи виправити пропущене посилання. Усе, що залежить від старого акаунта, потрібно вирішити до цього моменту, а не після.
Передумови, які слід підтвердити перед початком
Дві умови визначають, чи може перенесення взагалі відбутися:
Перенесення репозиторію вимагає прав адміністратора та сумісного акаунта отримувача без конфліктної назви репозиторію чи мережі форків. Джерело
На практиці це означає перевірку трьох речей на боці власника та однієї на боці отримувача, перш ніж щось запитувати:
| Перевірка | Хто підтверджує | Чому це блокує перенесення |
|---|---|---|
| Акаунт власника має права адміністратора на репозиторій | Власник | Без прав адміністратора перенесення неможливо ініціювати |
| Акаунт отримувача сумісний | Отримувач | Несумісний акаунт отримувача зупиняє перенесення |
| На боці отримувача ще не існує репозиторію з такою самою назвою | Отримувач | Конфліктна назва блокує переміщення |
| Немає конфліктної мережі форків | Отримувач | Конфліктна мережа форків блокує переміщення |
Якщо якийсь рядок не виконується, вирішіть це питання перед надсиланням запиту. Перейменування репозиторію на боці отримувача або вибір іншого цільового акаунта — це рішення отримувача, тож узгодьте їх заздалегідь, а не виявляйте конфлікт посеред перенесення.
Крок прийняття має короткий строк
Для перенесення між особистими акаунтами отримувач не є пасивною стороною. Він має діяти:
Для перенесення на інший особистий акаунт отримувач приймає запрошення електронною поштою, термін дії якого спливає через один день. Джерело
Одноденний термін дії — головний операційний ризик у цьому робочому процесі. Якщо отримувач в іншому часовому поясі, у відпустці або просто не стежить за поштою, запрошення може втратити чинність, і перенесення доведеться починати заново. Узгодьте час надсилання, коли отримувач доступний, і попросіть його очікувати на лист, а не залишати його непрочитаним.
Простий контрольний список для власника й отримувача:
- Власник: підтвердити права адміністратора, точний репозиторій для переміщення та відсутність у акаунта отримувача конфлікту назви чи мережі форків.
- Отримувач: підтвердити цільовий акаунт і перевірити ті самі конфлікти зі свого боку.
- Обидва: узгодити вікно надсилання, коли отримувач зможе відповісти протягом дня.
- Власник: надіслати запит на перенесення.
- Отримувач: своєчасно прийняти запрошення електронною поштою та повідомити про це.
- Власник: переконатися, що репозиторій тепер відображається під акаунтом отримувача, перш ніж щось робити зі старим акаунтом.
Не закривайте акаунт власника, доки не підтверджено крок 6. Старий акаунт — єдине місце, звідки можна повторно надіслати невдале або прострочене перенесення.
Що відбувається з публічними посиланнями згодом
Поведінка посилань — це те, чим перенесення дивує людей, адже два види посилань поводяться по-різному:
Посилання на репозиторій після перенесення перенаправляються, але пов’язані сайти GitHub Pages не перенаправляються; повторне використання старої адреси репозиторію скасовує перенаправлення репозиторію. Джерело
Це дає чіткий поділ для аудиту посилань після перенесення:
| Тип посилання | Після перенесення | Потрібна дія |
|---|---|---|
| Посилання на репозиторій, що вказують на стару адресу | Перенаправляються на нового власника | Зазвичай нічого; перевірте вибірку |
| Сайт GitHub Pages, створений з репозиторію | Не перенаправляється | Оновіть усі опубліковані посилання на сайт Pages |
| Стару адресу репозиторію повторно використав хтось інший | Перенаправлення скасовано | Уникайте звільнення старої адреси; підтримуйте посилання актуальними |
Третій рядок найімовірніше залишиться поза увагою. Якщо старий шлях репозиторію згодом буде повторно використано, перенаправлення, яке тихо прикривало ваші старі посилання, зникне. Сприймайте перенаправлення як зручність під час міграції, а не як постійну гарантію, і оновлюйте посилання, які ви контролюєте, замість того щоб покладатися на нього.
Контрольний список публічних посилань після перенесення
Виконайте це після того, як отримувач підтвердить право власності, і до закриття акаунта власника:
- Відкрийте вибірку посилань на репозиторій з вашої документації, README та будь-якого сайту, що посилається на проєкт, і переконайтеся, що вони ведуть до нового власника.
- Визначте кожен сайт GitHub Pages, пов’язаний з репозиторієм, оскільки вони не перенаправляються, і оновіть опубліковані посилання на них.
- Вирішіть, що станеться зі старою адресою репозиторію, щоб її не використали повторно в спосіб, який скасує перенаправлення.
- Перевірте посилання з місць, які ви не контролюєте, як-от зовнішні огляди чи спільні закладки, і занотуйте, які з них ви можете оновити, а які ні.
- Залишайте акаунт власника активним, доки все вищезазначене не буде виконано.
Міграція права власності проти зміни імені користувача
Перенесення репозиторію та зміна імені користувача профілю — це окремі завдання з окремими ризиками. Перенесення стосується того, кому належить проєкт; зміна імені користувача стосується власної публічної ідентичності акаунта. Якщо ви насправді хочете впорядкувати те, як виглядає ваш профіль, а не передати репозиторій, почніть з посібника зі зміни імені користувача: зміна імені користувача GitHub без залишення зламаних посилань профілю.
Якщо ви робите і те, і інше, послідовність має бути свідомою: спершу вирішіть питання права власності на репозиторій, переконайтеся, що новий власник може діяти самостійно, і лише потім змінюйте або закривайте старий акаунт. Зворотний порядок залишить перенесення залежним від акаунта, від якого ви вже відмовилися.
Де доречний пошук за іменем користувача, а де ні
Перед закриттям акаунта люди часто хочуть знати, які публічні сліди старого імені користувача залишилися в інших місцях. Пошук за іменем користувача може виявити збіги публічних профілів на інших платформах, що корисно як список зачіпок для посилань, які вам, можливо, потрібно оновити. Це не інвентаризація акаунтів, і збіг не є доказом того, що обома акаунтами володіє одна й та сама особа. Сприймайте результати як місця для ручної перевірки, а не як підтвердження, що посилання робоче або що акаунт належить вам.
TraceSeek охоплює 3 000+ платформ і повертає безкоштовний перший скан за 20–30 секунд. Це може допомогти скласти контрольний список публічних профілів для перегляду, але не підтверджує право власності й не замінює перевірки перенесення та посилань, наведені вище. Саме перенесення репозиторію відбувається на GitHub, а не в інструменті пошуку.
Реалістичний порядок дій
- Вирішіть, чи потрібне вам перенесення репозиторію, зміна імені користувача чи обидва варіанти.
- Підтвердіть права адміністратора, сумісність отримувача та відсутність конфлікту назви чи мережі форків.
- Надішліть запит на перенесення, коли отримувач зможе прийняти його протягом дня.
- Переконайтеся, що репозиторій перебуває під новим власником.
- Перевірте посилання на репозиторій і окремо — будь-які посилання на GitHub Pages.
- Захистіть стару адресу репозиторію від повторного використання.
- Лише після цього закривайте акаунт власника.