Chapters ▾ 2nd Edition

6.3 GitHub - Die Instandhouding van 'n Projek (Maintaining a Project)

Die Instandhouding van 'n Projek (Maintaining a Project)

Noudat ons gemaklik is om tot 'n projek by te dra, kom ons kyk na die ander kant: die skep, instandhouding en administrasie van jou eie projek.

Die Skep van 'n Nuwe Bewaarplek (Creating a New Repository)

Kom ons skep 'n nuwe bewaarplek (repository) om ons projekkode mee te deel. Begin deur op die “New repository” knoppie aan die regterkant van die kontroleskerm (dashboard) te klik, of van die + knoppie in die boonste nutsbalk langs jou gebruikersnaam soos gesien in Die “New repository” aftrekkieslys.

The “Your repositories” area
Figure 122. Die “Your repositories” area
The “New repository” dropdown
Figure 123. Die “New repository” aftrekkieslys

Dit neem jou na die “new repository” vorm:

The “new repository” form
Figure 124. Die “new repository” vorm

Al wat jy werklik hier hoef te doen is om 'n projeknaam te verskaf; die res van die velde is heeltemal opsioneel. Vir nou, klik net op die “Create Repository” knoppie, en doef — jy het 'n nuwe bewaarplek op GitHub, genaamd <user>/<project_name>.

Aangesien jy nog geen kode daar het nie, sal GitHub vir jou instruksies wys oor hoe om 'n splinternuwe Git-bewaarplek te skep, of 'n bestaande Git-projek te koppel. Ons gaan nie nou hierby stilstaan nie; as jy 'n opknapping nodig het, kyk na Git Basics.

Noudat jou projek op GitHub gehuisves word, kan jy die URL gee aan enigiemand met wie jy jou projek wil deel. Elke projek op GitHub is toeganklik oor HTTPS as https://github.com/<user>/<project_name>, en oor SSH as git@github.com:<user>/<project_name>. Git kan van albei hierdie URL’s afhaal (fetch) en daarnatoe opstuur (push), maar hulle word toegangsbeheer gebaseer op die aanmeldbewyse (credentials) van die gebruiker wat daaraan koppel.

Note

Dit is dikwels verkieslik om die HTTPS-gebaseerde URL vir 'n openbare projek te deel, aangesien die gebruiker nie 'n GitHub-rekening hoef te hê om toegang daartoe te kry vir kloning nie. Gebruikers sal 'n rekening en 'n opgelaaide SSH-sleutel moet hê om toegang tot jou projek te kry as jy vir hulle die SSH-URL gee. Die HTTPS-een is ook presies dieselfde URL wat hulle in 'n blaaier sou plak om die projek daar te bekyk.

Medewerkers Byvoeg (Adding Collaborators)

As jy met ander mense werk aan wie jy vasleggingstoegang (commit access) wil gee, moet jy hulle as “medewerkers” (collaborators) byvoeg. As Ben, Jeff en Louise almal vir rekeninge op GitHub inteken, en jy wil hulle push-toegang tot jou bewaarplek gee, kan jy hulle by jou projek voeg. Deur dit te doen sal hulle “push” toegang gee, wat beteken hulle het beide lees- en skryftoegang tot die projek en Git-bewaarplek.

Klik op die “Settings” skakel onderaan die regterkantste kantbalk.

The repository settings link
Figure 125. Die bewaarplek-instellingsskakel

Kies dan “Collaborators” uit die kieslys aan die linkerkant. Tik dan net 'n gebruikersnaam in die boks in, en klik op “Add collaborator.” Jy kan dit soveel keer herhaal as wat jy wil om toegang te verleen aan almal wat jy wil. As jy toegang moet intrek, klik net op die “X” aan die regterkant van hul ry.

The repository collaborators box
Figure 126. Die bewaarplek-medewerkersboks

Bestuur van Pull Requests (Managing Pull Requests)

Noudat jy 'n projek het met 'n bietjie kode daarin en dalk selfs 'n paar medewerkers wat ook push-toegang het, kom ons gaan oor wat om te doen wanneer jy self 'n Pull Request kry.

Pull Requests kan óf kom van 'n tak in 'n vurk (fork) van jou bewaarplek óf hulle kan kom van 'n ander tak in dieselfde bewaarplek. Die enigste verskil is dat dié in 'n vurk dikwels van mense is waar jy nie na hul tak kan push nie en hulle nie na joune kan push nie, terwyl met interne Pull Requests beide partye oor die algemeen toegang tot die tak kan kry.

Vir hierdie voorbeelde, kom ons aanvaar jy is “tonychacon” en jy het 'n nuwe Arduino-kode-projek genaamd “fade” geskep.

E-poskennisgewings (Email Notifications)

Iemand kom verby en maak 'n verandering aan jou kode en stuur vir jou 'n Pull Request. Jy behoort 'n e-pos te kry wat jou in kennis stel van die nuwe Pull Request en dit behoort min of meer te lyk soos E-poskennisgewing van 'n nuwe Pull Request.

Email notification of a new Pull Request
Figure 127. E-poskennisgewing van 'n nuwe Pull Request

Daar is 'n paar dinge om op te let oor hierdie e-pos. Dit sal jou 'n klein diffstat gee — 'n lys van lêers wat in die Pull Request verander het en met hoeveel. Dit gee jou 'n skakel na die Pull Request op GitHub. Dit gee jou ook 'n paar URL’s wat jy vanaf die opdragreël kan gebruik.

As jy die reël opmerk wat sê git pull <url> patch-1, is dit 'n eenvoudige manier om 'n afgeleë tak in te smelt (merge) sonder om 'n remote by te voeg. Ons het vinnig hieroor gegaan in Uitcheck van Afgeleë Takke (Checking Out Remote Branches). As jy wil, kan jy skep en oorskakel na 'n onderwerp-tak (topic branch) en dan hierdie opdrag uitvoer om die Pull Request-veranderings in te smelt.

Die ander interessante URL’s is die .diff en .patch URL’s, wat soos jy dalk kan raai, verenigde diff (unified diff) en pleisterweergawes van die Pull Request verskaf. Jy kan tegnies die Pull Request-werk insmelt met iets soos dit:

$ curl https://github.com/tonychacon/fade/pull/1.patch | git am

Samewerking op die Pull Request (Collaborating on the Pull Request)

Soos ons gedek het in Die GitHub-vloei (flow [flow]), kan jy nou 'n gesprek hê met die persoon wat die Pull Request oopgemaak het. Jy kan kommentaar lewer op spesifieke reëls kode, kommentaar lewer op hele vasleggings (commits) of kommentaar lewer op die hele Pull Request self, deur GitHub-gegeurde Markdown (GitHub Flavored Markdown) oral te gebruik.

Elke keer as iemand anders kommentaar lewer op die Pull Request sal jy aanhou om e-poskennisgewings te kry sodat jy weet daar is aktiwiteit besig om te gebeur. Hulle sal elkeen 'n skakel hê na die Pull Request waar die aktiwiteit plaasvind en jy kan ook direk op die e-pos reageer om op die Pull Request-draad kommentaar te lewer.

Responses to emails are included in the thread
Figure 128. Antwoorde op e-posse word in die draad ingesluit

Sodra die kode op 'n plek is waarvan jy hou en dit wil insmelt, kan jy óf die kode aftrek (pull) en dit plaaslik insmelt, óf met die git pull <url> <branch> sintaksis wat ons vroeër gesien het, óf deur die vurk as 'n remote by te voeg en te fetch en te merge.

As die saamsmelting triviaal is, kan jy ook net die “Merge” knoppie op die GitHub-webwerf druk. Dit sal 'n “non-fast-forward” saamsmelting doen, en 'n saamsmeltingsvaslegging (merge commit) skep selfs al was 'n vinnig-vorentoe (fast-forward) saamsmelting moontlik. Dit beteken dat, wat ook al gebeur, elke keer as jy die saamsmelting-knoppie druk, 'n saamsmeltingsvaslegging geskep word. Soos jy kan sien in Merge-knoppie en instruksies vir die handmatige saamsmelting van 'n Pull Request, gee GitHub jou al hierdie inligting as jy op die wenkskakel klik.

Merge button and instructions for merging a Pull Request manually
Figure 129. Merge-knoppie en instruksies vir die handmatige saamsmelting van 'n Pull Request

As jy besluit jy wil dit nie insmelt nie, kan jy ook net die Pull Request sluit en die persoon wat dit geopen het, sal in kennis gestel word.

Pull Request-verwysings (Pull Request Refs)

As jy met 'n klomp Pull Requests te doen het en nie 'n klomp remotes wil byvoeg of eenmalige pulls elke keer wil doen nie, is daar 'n netjiese truuk wat GitHub jou toelaat om te doen. Hierdie is 'n bietjie van 'n gevorderde truuk en ons sal die besonderhede hiervan 'n bietjie meer in Die Refspec (Verwysingspesifikasie) deurgaan, maar dit kan redelik nuttig wees.

GitHub adverteer eintlik die Pull Request-takke vir 'n bewaarplek as 'n soort pseudo-takke op die bediener. By verstek kry jy dit nie wanneer jy kloon nie, maar dit is daar op 'n verborge manier en jy kan redelik maklik toegang daartoe kry.

Om dit te demonstreer, gaan ons 'n laevlakopdrag gebruik (daar word dikwels na verwys as 'n “loodgieterswerk” / “plumbing” opdrag, waaroor ons meer sal lees in Loodgieterswerk en Porselein (Plumbing and Porcelain)) genaamd ls-remote. Hierdie opdrag word oor die algemeen nie in dag-tot-dag Git-bedrywighede gebruik nie, maar dit is nuttig om vir ons te wys watter verwysings op die bediener teenwoordig is.

As ons hierdie opdrag uitvoer teen die “blink” bewaarplek wat ons vroeër gebruik het, sal ons 'n lys kry van al die takke en merkers en ander verwysings in die bewaarplek.

$ git ls-remote https://github.com/schacon/blink
10d539600d86723087810ec636870a504f4fee4d	HEAD
10d539600d86723087810ec636870a504f4fee4d	refs/heads/master
6a83107c62950be9453aac297bb0193fd743cd6e	refs/pull/1/head
afe83c2d1a70674c9505cc1d8b7d380d5e076ed3	refs/pull/1/merge
3c8d735ee16296c242be7a9742ebfbc2665adec1	refs/pull/2/head
15c9f4f80973a2758462ab2066b6ad9fe8dcf03d	refs/pull/2/merge
a5a7751a33b7e86c5e9bb07b26001bb17d775d1a	refs/pull/4/head
31a45fc257e8433c8d8804e3e848cf61c9d3166c	refs/pull/4/merge

Natuurlik, as jy in jou bewaarplek is en jy voer git ls-remote origin uit, of watter remote jy ook al wil nagaan, sal dit jou iets soortgelyks aan dit wys.

As die bewaarplek op GitHub is en jy het enige Pull Requests wat geopen is, sal jy hierdie verwysings kry wat voorafgegaan word met refs/pull/. Dit is basies takke, maar aangesien dit nie onder refs/heads/ is nie, kry jy dit normaalweg nie wanneer jy kloon of van die bediener afhaal (fetch) nie — die proses van afhaling ignoreer dit normaalweg.

Daar is twee verwysings per Pull Request - die een wat op /head eindig, wys na presies dieselfde vaslegging as die laaste vaslegging in die Pull Request-tak. So as iemand 'n Pull Request in ons bewaarplek open en hul tak word bug-fix genoem en dit wys na vaslegging a5a775, dan sal ons in ons bewaarplek nie 'n bug-fix tak hê nie (aangesien dit in hul vurk is), maar ons sal pull/<pr#>/head hê wat na a5a775 wys. Dit beteken dat ons redelik maklik elke Pull Request-tak in een slag kan aftrek sonder om 'n klomp remotes by te voeg.

Nou kan jy iets doen soos om die verwysing direk af te haal.

$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
 * branch            refs/pull/958/head -> FETCH_HEAD

Dit sê vir Git: “Koppel aan die origin remote, en laai die verwysing genaamd refs/pull/958/head af.” Git gehoorsaam vrolik, en laai alles af wat jy nodig het om daardie verwysing saam te stel, en plaas 'n wyser na die vaslegging wat jy wil hê onder .git/FETCH_HEAD. Jy kan dit opvolg met git merge FETCH_HEAD in 'n tak waarin jy dit wil toets, maar daardie saamsmeltingsvasleggingsboodskap lyk 'n bietjie vreemd. Ook, as jy 'n klomp pull requests hersien, raak dit vervelig.

Daar is ook 'n manier om al die pull requests af te haal, en hulle op datum te hou wanneer jy ook al aan die remote koppel. Maak .git/config oop in jou gunsteling redigeerder (editor), en soek die origin remote. Dit behoort 'n bietjie soos volg te lyk:

[remote "origin"]
    url = https://github.com/libgit2/libgit2
    fetch = +refs/heads/*:refs/remotes/origin/*

Daardie reël wat met fetch = begin is 'n “refspec.” Dit is 'n manier om name op die remote te karteer (map) met name in jou plaaslike .git gids. Hierdie spesifieke een sê vir Git: "die dinge op die remote wat onder refs/heads is, moet in my plaaslike bewaarplek onder refs/remotes/origin gaan." Jy kan hierdie afdeling wysig om nog 'n refspec by te voeg:

[remote "origin"]
    url = https://github.com/libgit2/libgit2.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Daardie laaste reël sê vir Git: “Al die verwysings wat soos refs/pull/123/head lyk, moet plaaslik gestoor word soos refs/remotes/origin/pr/123.” Nou, as jy daardie lêer stoor en 'n git fetch doen:

$ git fetch
# …
 * [new ref]         refs/pull/1/head -> origin/pr/1
 * [new ref]         refs/pull/2/head -> origin/pr/2
 * [new ref]         refs/pull/4/head -> origin/pr/4
# …

Nou word al die afgeleë pull requests plaaslik verteenwoordig met verwysings wat baie soos opsporingstakke (tracking branches) optree; hulle is leesalleen (read-only), en hulle werk op wanneer jy 'n fetch doen. Dit maak dit super maklik om die kode van 'n pull request plaaslik te probeer:

$ git checkout pr/2
Checking out files: 100% (3769/3769), done.
Branch pr/2 set up to track remote branch pr/2 from origin.
Switched to a new branch 'pr/2'

Die arendsoë onder julle sal die head aan die einde van die afgeleë gedeelte van die refspec oplet. Daar is ook 'n refs/pull/#/merge verwysing aan die GitHub-kant, wat die vaslegging verteenwoordig wat sou volg as jy die “merge” knoppie op die webwerf druk. Dit kan jou toelaat om die saamsmelting te toets voordat jy selfs die knoppie druk.

Pull Requests op Pull Requests

Nie net kan jy Pull Requests oopmaak wat die main of master tak teiken nie, jy kan eintlik 'n Pull Request oopmaak wat enige tak in die netwerk teiken. Trouens, jy kan selfs 'n ander Pull Request teiken.

As jy 'n Pull Request sien wat in die regte rigting beweeg en jy het 'n idee vir 'n verandering wat daarvan afhang of jy nie seker is dat dit 'n goeie idee is nie, of jy het net nie push-toegang tot die teikentak nie, kan jy 'n Pull Request direk daaraan oopmaak.

Wanneer jy gaan om 'n Pull Request oop te maak, is daar 'n boksie aan die bokant van die bladsy wat spesifiseer na watter tak jy versoek om te pull en van watter jy versoek om te pull. As jy die “Edit” knoppie regs van daardie boksie druk, kan jy nie net die takke verander nie, maar ook watter vurk.

Manually change the Pull Request target fork and branch
Figure 130. Verander die Pull Request teikenvurk en -tak handmatig

Hier kan jy redelik maklik spesifiseer om jou nuwe tak in 'n ander Pull Request of 'n ander vurk van die projek in te smelt.

Vermeldings en Kennisgewings (Mentions and Notifications)

GitHub het ook 'n redelik oulike kennisgewingstelsel ingebou wat handig te pas kan kom wanneer jy vrae het of terugvoer van spesifieke individue of spanne benodig.

In enige opmerking kan jy 'n @ karakter begin tik en dit sal begin outovoltooi met die name en gebruikersname van mense wat medewerkers of bydraers in die projek is.

Start typing @ to mention someone
Figure 131. Begin @ tik om iemand te vermeld

Jy kan ook 'n gebruiker vermeld wat nie in daardie aftrekkieslys is nie, maar dikwels kan die outovoltooier dit vinniger maak.

Sodra jy 'n opmerking met 'n gebruikersvermelding plaas, sal daardie gebruiker in kennis gestel word. Dit beteken dit kan 'n baie doeltreffende manier wees om mense in gesprekke in te trek eerder as om hulle te laat soek of wag (poll). Baie dikwels in Pull Requests op GitHub sal mense ander mense in hul spanne of in hul maatskappy intrek om 'n Issue of Pull Request te hersien.

As iemand op 'n Pull Request of Issue vermeld word, sal hulle daarop “geabonneer” (subscribed) word en sal hulle aanhou om kennisgewings te kry enige tyd as daar aktiwiteit daarop plaasvind. Jy sal ook op iets geabonneer wees as jy dit oopgemaak het, as jy die bewaarplek volg (watching) of as jy op iets kommentaar lewer. As jy nie meer kennisgewings wil ontvang nie, is daar 'n “Unsubscribe” (Teken uit) knoppie op die bladsy waarop jy kan klik om op te hou om opdaterings daaroor te ontvang.

Unsubscribe from an Issue or Pull Request
Figure 132. Teken uit (unsubscribe) van 'n Issue of Pull Request

Die Kennisgewingsblad (The Notifications Page)

Wanneer ons hier "kennisgewings" noem met betrekking tot GitHub, bedoel ons 'n spesifieke manier waarop GitHub probeer om met jou in kontak te kom wanneer gebeure plaasvind en daar is 'n paar verskillende maniere waarop jy hulle kan konfigureer. As jy na die “Notification center” oortjie vanaf die instellingsblad gaan, kan jy sommige van die opsies wat jy het, sien.

Notification center options
Figure 133. Kennisgewingsentrum opsies

Die twee keuses is om kennisgewings oor “Email” en oor “Web” te kry, en jy kan enige, geeneen of albei kies vir wanneer jy aktief aan dinge deelneem en vir aktiwiteit op bewaarplekke wat jy volg.

Webkennisgewings (Web Notifications)

Webkennisgewings bestaan net op GitHub en jy kan dit net op GitHub nagaan. As jy hierdie opsie gekies het in jou voorkeure en 'n kennisgewing word vir jou geaktiveer, sal jy 'n klein blou kolletjie bo jou kennisgewing-ikoon aan die bokant van jou skerm sien soos gesien in Kennisgewingsentrum.

Notification center
Figure 134. Kennisgewingsentrum

As jy daarop klik, sal jy 'n lys sien van al die items waaroor jy in kennis gestel is, gegroepeer volgens projek. Jy kan filter tot die kennisgewings van 'n spesifieke projek deur op sy naam in die linkerkantse kantbalk te klik. Jy kan ook die kennisgewing erken deur op die regmerkie-ikoon langs enige kennisgewing te klik, of al die kennisgewings in 'n projek te erken deur op die regmerkie bo-aan die groep te klik. Daar is ook 'n demp-knoppie (mute) langs elke regmerkie waarop jy kan klik om geen verdere kennisgewings oor daardie item te ontvang nie.

Al hierdie gereedskap is baie nuttig vir die hantering van groot getalle kennisgewings. Baie GitHub-kraggebruikers sal eenvoudig e-poskennisgewings heeltemal afskakel en al hul kennisgewings deur hierdie skerm bestuur.

E-poskennisgewings (Email Notifications)

E-poskennisgewings is die ander manier waarop jy kennisgewings deur GitHub kan hanteer. As jy dit aangeskakel het, sal jy e-posse kry vir elke kennisgewing. Ons het voorbeelde hiervan gesien in E-poskennisgewings (Email Notifications) en E-poskennisgewing van 'n nuwe Pull Request. Die e-posse sal ook behoorlik in drade (threaded) geplaas word, wat lekker is as jy 'n draad-gebaseerde e-poskliënt gebruik.

Daar is ook 'n redelike hoeveelheid metadata ingebed in die opskrifte van die e-posse wat GitHub vir jou stuur, wat regtig nuttig kan wees vir die opstel van pasgemaakte filters en reëls.

Byvoorbeeld, as ons na die werklike e-posopskrifte kyk wat aan Tony gestuur is in die e-pos wat in E-poskennisgewing van 'n nuwe Pull Request gewys word, sal ons die volgende onder die inligting wat gestuur is, sien:

To: tonychacon/fade <fade@noreply.github.com>
Message-ID: <tonychacon/fade/pull/1@github.com>
Subject: [fade] Wait longer to see the dimming effect better (#1)
X-GitHub-Recipient: tonychacon
List-ID: tonychacon/fade <fade.tonychacon.github.com>
List-Archive: https://github.com/tonychacon/fade
List-Post: <mailto:reply+i-4XXX@reply.github.com>
List-Unsubscribe: <mailto:unsub+i-XXX@reply.github.com>,...
X-GitHub-Recipient-Address: tchacon@example.com

Hier is 'n paar interessante dinge. As jy e-posse wil uitlig of herlei na hierdie spesifieke projek of selfs Pull Request, gee die inligting in Message-ID vir jou al die data in <user>/<project>/<type>/<id> formaat. As dit byvoorbeeld 'n issue was, sou die <type> veld “issues” gewees het in plaas van “pull”.

Die List-Post en List-Unsubscribe velde beteken dat as jy 'n e-poskliënt het wat dit verstaan, jy maklik na die lys kan plaas of van die draad kan “Unsubscribe”. Dit sou in wese dieselfde wees as om op die “mute” knoppie op die webweergawe van die kennisgewing of “Unsubscribe” op die Issue- of Pull Request-blad self te klik.

Dit is ook die moeite werd om te let op dat as jy beide e-pos- en webkennisgewings geaktiveer het en jy lees die e-posweergawe van die kennisgewing, die webweergawe ook as gelees gemerk sal word as jy prente in jou e-poskliënt toelaat.

Spesiale Lêers (Special Files)

Daar is 'n paar spesiale lêers wat GitHub sal oplet as dit in jou bewaarplek teenwoordig is.

README

Die eerste is die README lêer, wat in byna enige formaat kan wees wat GitHub as prosa herken. Byvoorbeeld, dit kan README, README.md, README.asciidoc, ens. wees. As GitHub 'n README lêer in jou bronkode sien, sal dit dit op die landingsblad van die projek weergee.

Baie spanne gebruik hierdie lêer om al die relevante projekinligting te hou vir iemand wat dalk nuut in die bewaarplek of projek is. Dit sluit gewoonlik dinge in soos:

  • Waarvoor die projek is

  • Hoe om dit op te stel en te installeer

  • 'n Voorbeeld van hoe om dit te gebruik of dit aan die gang te kry

  • Die lisensie waaronder die projek aangebied word

  • Hoe om daartoe by te dra

Aangesien GitHub hierdie lêer sal weergee, kan jy prente of skakels daarin insluit vir bykomende begrip.

CONTRIBUTING

Die ander spesiale lêer wat GitHub herken is die CONTRIBUTING lêer. As jy 'n lêer genaamd CONTRIBUTING met enige lêeruitbreiding het, sal GitHub Oopmaak van 'n Pull Request wanneer 'n CONTRIBUTING lêer bestaan wys wanneer enigiemand 'n Pull Request begin oopmaak.

Opening a Pull Request when a CONTRIBUTING file exists
Figure 135. Oopmaak van 'n Pull Request wanneer 'n CONTRIBUTING lêer bestaan

Die idee hier is dat jy spesifieke dinge kan spesifiseer wat jy wil of nie wil hê nie in 'n Pull Request wat na jou projek gestuur word. Op hierdie manier mag mense werklik die riglyne lees voordat hulle die Pull Request oopmaak.

Projekadministrasie (Project Administration)

Oor die algemeen is daar nie baie administratiewe dinge wat jy met 'n enkele projek kan doen nie, maar daar is 'n paar items wat van belang kan wees.

Verandering van die Verstek-tak (Changing the Default Branch)

As jy 'n ander tak as “master” gebruik as jou verstek-tak waarop jy wil hê mense Pull Requests moet oopmaak of by verstek moet sien, kan jy dit verander in jou bewaarplek se instellingsblad onder die “Options” oortjie.

Change the default branch for a project
Figure 136. Verander die verstek-tak vir 'n projek

Verander eenvoudig die verstek-tak in die aftrekkieslys en dit sal van toe af die verstek wees vir alle groot bewerkings, insluitend watter tak by verstek uitgetrek (checked out) word wanneer iemand die bewaarplek kloon.

Oordrag van 'n Projek (Transferring a Project)

As jy 'n projek na 'n ander gebruiker of 'n organisasie in GitHub wil oordra, is daar 'n “Transfer ownership” opsie onderaan dieselfde “Options” oortjie van jou bewaarplekinstellingsblad wat jou toelaat om dit te doen.

Transfer a project to another GitHub user or Organization
Figure 137. Dra 'n projek oor na 'n ander GitHub-gebruiker of Organisasie

Dit is nuttig as jy 'n projek laat vaar en iemand dit wil oorneem, of as jou projek groter word en jy dit na 'n organisasie wil skuif.

Dit skuif nie net die bewaarplek saam met al sy volgers (watchers) en sterre (stars) na 'n ander plek nie, dit stel ook 'n herleiding van jou URL na die nuwe plek op. Dit sal ook klone en fetch-aksies van Git herlei, nie net webversoeke nie.