Wat de overdracht feitelijk verandert
Een GitHub-repositoryoverdracht verplaatst de repository naar een ander eigenaarsaccount. Dit is niet dezelfde handeling als het wijzigen van je profielgebruikersnaam. Een gebruikersnaam wijzigen verandert de openbare identiteit van het account en de URL’s die daarop zijn gebaseerd; een repository overdragen verandert wie eigenaar is van dat ene project. Als je doel een schonere profielnaam is in plaats van een project aan iemand anders overdragen, dan zijn de onderstaande overdrachtsstappen het verkeerde middel.
Het onderscheid is belangrijk voor de planning. Zodra het oorspronkelijke eigenaarsaccount is opgeheven, kan niemand meer inloggen om uitnodigingen te accepteren, vervolgstappen goed te keuren of een gemiste link te corrigeren. Alles wat van het oude account afhangt, moet vóór dat moment zijn geregeld, niet erna.
Voorwaarden om vóór je begint te bevestigen
Twee voorwaarden bepalen of een overdracht überhaupt kan doorgaan:
Een repositoryoverdracht vereist beheerdersrechten en een compatibel ontvangend account zonder conflicterende repositorynaam of fork-netwerk. Bron
In de praktijk betekent dat drie dingen aan de eigenaarskant en één aan de ontvangerskant controleren voordat je iets aanvraagt:
| Controle | Wie bevestigt dit | Waarom het de overdracht blokkeert |
|---|---|---|
| Het eigenaarsaccount heeft beheerdersrechten op de repository | Eigenaar | Zonder beheerdersrechten kan de overdracht niet worden gestart |
| Het ontvangende account is compatibel | Ontvanger | Een incompatibel ontvangend account stopt de overdracht |
| Er bestaat nog geen repository met dezelfde naam bij de ontvanger | Ontvanger | Een conflicterende naam blokkeert de verplaatsing |
| Geen conflicterend fork-netwerk | Ontvanger | Een conflicterend fork-netwerk blokkeert de verplaatsing |
Als een van deze regels niet klopt, los het op voordat je het verzoek verstuurt. De repository hernoemen aan de ontvangerskant of een ander bestemmingsaccount kiezen zijn beslissingen aan de ontvangerskant, dus spreek die vooraf af in plaats van het conflict midden in de overdracht te ontdekken.
De acceptatiestap heeft een kort venster
Bij overdrachten tussen persoonlijke accounts is de ontvanger geen passieve partij. Die moet handelen:
Voor een overdracht naar een ander persoonlijk account accepteert de ontvanger een e-mailuitnodiging die na één dag verloopt. Bron
Een geldigheid van één dag is het grootste operationele risico in deze workflow. Als de ontvanger in een andere tijdzone zit, met verlof is of simpelweg de e-mail niet in de gaten houdt, kan de uitnodiging verlopen en moet de overdracht opnieuw worden gestart. Spreek een verzendtijd af waarop de ontvanger bereikbaar is, en laat die persoon weten dat het bericht komt in plaats van het ongelezen te laten liggen.
Een eenvoudige acceptatiechecklist voor eigenaar en ontvanger:
- Eigenaar: bevestig beheerdersrechten, de exacte repository die wordt verplaatst, en dat het account van de ontvanger geen naam- of fork-netwerkconflict heeft.
- Ontvanger: bevestig het bestemmingsaccount en controleer dezelfde conflicten van jouw kant.
- Beiden: spreek een verzendvenster af waarin de ontvanger binnen een dag kan reageren.
- Eigenaar: verstuur het overdrachtsverzoek.
- Ontvanger: accepteer de e-mailuitnodiging snel en meld dit terug.
- Eigenaar: bevestig dat de repository nu onder het account van de ontvanger verschijnt voordat je iets met het oude account doet.
Hecht het eigenaarsaccount pas op na bevestiging van stap 6. Het oude account is de enige plek van waaruit een mislukte of verlopen overdracht opnieuw kan worden verstuurd.
Wat er daarna met openbare links gebeurt
Linkgedrag is waar overdrachten mensen verrassen, omdat twee soorten links zich anders gedragen:
Repositorylinks verwijzen na de overdracht door, maar bijbehorende GitHub Pages-websites worden niet doorverwezen; hergebruik van de oude repositorylocatie maakt de repositoryredirect ongedaan. Bron
Dat geeft een duidelijke splitsing voor een linkcontrole na de overdracht:
| Linktype | Na de overdracht | Benodigde actie |
|---|---|---|
| Repositorylinks die naar de oude locatie wijzen | Verwijzen door naar de nieuwe eigenaar | Meestal niets; controleer een steekproef |
| GitHub Pages-site die uit de repository is gebouwd | Niet doorverwezen | Werk elke gepubliceerde link naar de Pages-site bij |
| Oude repositorylocatie hergebruikt door iemand anders | Redirect is verwijderd | Voorkom dat de oude locatie vrijkomt; houd links actueel |
De derde regel wordt het vaakst over het hoofd gezien. Als het oude repositorypad later opnieuw wordt gebruikt, verdwijnt de redirect die je oude links stilzwijgend dekte. Beschouw de redirect als een gemak tijdens de migratie, niet als een permanente garantie, en werk de links bij die je zelf beheert in plaats van erop te vertrouwen.
Checklist voor openbare links na de overdracht
Voer dit uit nadat de ontvanger het eigenaarschap heeft bevestigd en voordat het eigenaarsaccount wordt opgeheven:
- Open een steekproef van repositorylinks uit je documentatie, README’s en elke site die naar het project verwijst, en bevestig dat ze naar de nieuwe eigenaar verwijzen.
- Identificeer elke GitHub Pages-site die bij de repository hoort, omdat die niet worden doorverwezen, en werk de gepubliceerde links ernaar bij.
- Bepaal wat er met de oude repositorylocatie gebeurt, zodat die niet wordt hergebruikt op een manier die de redirect verwijdert.
- Controleer links vanaf plekken die je niet beheert, zoals externe artikelen of gedeelde bladwijzers, en noteer welke je wel en niet kunt bijwerken.
- Houd het eigenaarsaccount actief tot al het bovenstaande is gedaan.
Eigenaarschap migreren versus een gebruikersnaam wijzigen
Een repository overdragen en een profielgebruikersnaam wijzigen zijn afzonderlijke taken met afzonderlijke risico’s. Een overdracht gaat over wie eigenaar is van een project; een gebruikersnaamswijziging gaat over de openbare identiteit van het account zelf. Als je eigenlijk vooral wilt opruimen hoe je profiel verschijnt in plaats van een repository over te dragen, begin dan met de gebruikersnaamhandleiding: je GitHub-gebruikersnaam wijzigen zonder gebroken profiellinks achter te laten.
Als je beide doet, plan ze dan bewust in volgorde: regel eerst het eigenaarschap van de repository, bevestig dat de nieuwe eigenaar zelfstandig kan handelen, en wijzig of hef pas daarna het oude account op. Doe je het in de andere volgorde, dan blijft de overdracht afhankelijk van een account dat je al hebt opgegeven.
Waar een gebruikersnaamzoekopdracht past, en waar niet
Voordat mensen een account opheffen, willen ze vaak weten welke openbare sporen van de oude gebruikersnaam elders nog bestaan. Een gebruikersnaamopzoeking kan openbare profielmatches op andere platforms naar boven halen, wat nuttig is als lijst met links die je mogelijk moet bijwerken. Het is geen accountinventaris, en een match is geen bewijs dat dezelfde persoon eigenaar is van beide accounts. Behandel resultaten als plekken om handmatig te controleren, niet als bevestiging dat een link live is of dat een account van jou is.
TraceSeek dekt 3.000+ platforms en geeft een gratis eerste scan in 20-30 seconden. Dat kan helpen om een checklist van openbare profielen op te stellen die je wilt beoordelen, maar het verifieert geen eigenaarschap en vervangt niet de overdrachts- en linkcontroles hierboven. De repositoryoverdracht zelf gebeurt op GitHub, niet in een opzoekingstool.
Een realistische volgorde van handelingen
- Bepaal of je een repositoryoverdracht nodig hebt, een gebruikersnaamswijziging, of beide.
- Bevestig beheerdersrechten, compatibiliteit van de ontvanger en geen naam- of fork-netwerkconflict.
- Verstuur de overdracht wanneer de ontvanger binnen één dag kan accepteren.
- Bevestig dat de repository onder de nieuwe eigenaar staat.
- Controleer repositorylinks en, apart daarvan, eventuele GitHub Pages-links.
- Bescherm de oude repositorylocatie tegen hergebruik.
- Hef pas daarna het eigenaarsaccount op.