5. témakör · Csapatmunka GitHubon · 22. fejezet
Eddig olyan repókban dolgoztál, ahová írási jogod volt. De mi van, ha egy társad projektjében, egy iskolai sablonban vagy egy nyílt forráskódú programban találsz hibát? Oda nem tölthetsz fel. Ilyenkor forkolsz: lemásolod a repót a saját fiókodba, ott dolgozol, és pull requesttel javasolod a változást az eredetinek. Ebben a fejezetben végigjárod ezt az utat, és azt is megtanulod, hogyan tartsd szinkronban a forkodat.
upstream remote-ot.origin és mi az upstream szerepe egy fork esetén.git fetch upstream + merge + push parancssorból.A fork egy repó másolata a saját GitHub-fiókodban. Olyan, mintha a GitHubon belül klónoznád: minden commit, ág és címke átkerül, de a másolat a tiéd, oda szabadon feltölthetsz. A fork kapcsolatban marad az eredetivel: a repó neve alatt ott áll, hogy forked from toth-peter/receptek, és innen nyithatsz pull requestet az eredetibe.
| Ág (branch) | Fork | Klón (clone) | |
|---|---|---|---|
| Hol jön létre? | ugyanabban a repóban | a GitHubon, a te fiókodban | a gépeden |
| Kell írási jog az eredetihez? | igen | nem | nem (olvasáshoz) |
| Mire jó? | csapattagok párhuzamos munkája | hozzájárulás idegen repóhoz, saját továbbfejlesztés | helyi munka bármelyik repón |
| Hogyan kerül vissza a munka? | PR ugyanabban a repóban | PR a forkból az eredetibe | git push (ha van jogod) |
Ha egy csapatban dolgoztok, egyszerűbb, ha a repó gazdája meghív titeket collaborator-nak (Settings → Collaborators): akkor mindenki ágakkal dolgozik ugyanabban a repóban (20. fejezet). A fork akkor kell, ha nincs írási jogod, és nem is kapsz: nyílt forráskódú projekt, más osztály repója, egy tanári sablon.
Három hely vesz részt benne: az eredeti repó (upstream), a forkod (origin) és a géped. Lépkedj végig!
anna-kovacs/receptek, alatta: forked from toth-peter/receptek.PS> git clone https://github.com/anna-kovacs/receptek.git Cloning into 'receptek'... PS> cd receptek
A saját repódat nem tudod a saját fiókodba forkolni (már ott van). Ugyanazt a repót egy fiókba csak egyszer lehet forkolni: ha újra megnyomod, a GitHub a meglévő forkodhoz visz.
A klónozás után az origin a forkodra mutat. Az eredeti repót neked kell hozzáadni; a szokásos neve upstream:
PS> git remote add upstream https://github.com/toth-peter/receptek.git PS> git remote -v origin https://github.com/anna-kovacs/receptek.git (fetch) origin https://github.com/anna-kovacs/receptek.git (push) upstream https://github.com/toth-peter/receptek.git (fetch) upstream https://github.com/toth-peter/receptek.git (push)
| Remote | Mire mutat? | Mit csinálsz vele? |
|---|---|---|
origin | a forkod (anna-kovacs/receptek) | git push: ide töltöd fel az ágaidat; ide van írási jogod |
upstream | az eredeti (toth-peter/receptek) | git fetch upstream: innen hozod le a friss állapotot; ide nem tudsz push-olni |
A remote neve csak megállapodás (a Git nem tudja, mi az „upstream”), de ezt a nevet mindenki ismeri, ezért maradj ennél.
Melyik remote-ról van szó? (Anna forkolta Péter repóját.)
PS> git switch -c fix/palacsinta # mindig külön ágon! # … javítás … PS> git commit -am "docs: sütési lépés a palacsinta receptben" PS> git push -u origin fix/palacsinta # a forkodba
A forkod oldalán megjelenik a Compare & pull request sáv. A PR-oldal ilyenkor két repót hasonlít össze (comparing across forks):
git push — a PR frissül.A forkod nem frissül magától. Ha az eredetibe új commitok érkeznek (például a te PR-od beolvasztása), a forkod lemarad: a GitHub ki is írja, This branch is 2 commits behind toth-peter/receptek:main. Két út van:
A weben: Sync fork
git switch main, git pull.Parancssorból
PS> git fetch upstream PS> git switch main PS> git merge upstream/main # előretolás PS> git push origin main # a fork is frissül
A forkod main ágára ne commitolj saját munkát: minden változás külön ágon készüljön. Így a szinkron mindig egyszerű előretolás (fast-forward), soha nincs ütközés.
Egy még nyitott PR ágát a friss main-re a 14. fejezet módszerével húzhatod (git merge main vagy git rebase main az ágon).
Merge után a rendrakás a forkban is esedékes: git branch -d fix/palacsinta helyben, és git push origin --delete fix/palacsinta
a forkodban (vagy a PR oldalán a Delete branch).
CONTRIBUTING.md-t, ha van: leírja, milyen ágnevet, commitüzenetet, tesztet vár a projekt.LICENSE fájlt: ez mondja meg, mit szabad kezdeni a kóddal (pl. MIT: szabadon használható, a szerző megnevezésével).
Licenc nélkül a kód jogilag nem szabadon felhasználható, akkor sem, ha nyilvános.upstream remote-ot, és a PR-okat az eredeti repóba nyitja.upstream/main-t; utána Push origin.upstream, URL: az eredeti repó címe.upstream/main.Péter nyilvános receptgyűjteményében (toth-peter/receptek) hiányzik a palacsinta sütési lépése. Írási jogod nincs: forkolj, javíts, nyiss PR-t,
és utána hozd szinkronba a forkodat!
⭐ alap · ⭐⭐ haladó · ⭐⭐⭐ kihívás
Forkold egy társad nyilvános gyakorló repóját. Nézd meg a forked from sort, és az eredeti repóban a Fork gomb melletti számlálót.
Klónozd a forkodat, add hozzá az eredetit upstream néven, és ellenőrizd: git remote -v. Hány sort ír ki, és miért?
Javíts egy elírást egy külön ágon, töltsd fel a forkodba, és nyiss PR-t az eredeti repóba. A társad nézze át és olvassza be.
A beolvasztás után szinkronizáld a forkod main-jét parancssorból: git fetch upstream, git merge upstream/main,
git push origin main. Ellenőrizd a GitHubon, hogy eltűnt-e a behind jelzés.
Klónozd a forkodat GitHub Desktoppal, válaszd a To contribute to the parent project lehetőséget, majd nézd meg a Repository settings ablakban, milyen remote-ok lettek beállítva.
Használd a Sync fork gombot, majd a gépeden git pull. Írd le, miben más ez, mint a parancssoros szinkron.
Nézd meg egy nagy nyílt forráskódú projekt (pl. a github/docs) CONTRIBUTING.md fájlját. Milyen lépéseket kér egy hozzájárulás előtt? Foglald össze öt pontban.
Az egyválasztós kérdéseknél kattints a válaszra. A többválasztósaknál jelöld be az összes helyeset, majd nyomd meg az Ellenőrzés gombot.
| Fogalom | Jelentés |
|---|---|
| fork | egy repó másolata a saját GitHub-fiókodban, amely kapcsolatban marad az eredetivel |
| upstream | az eredeti repó; a szokásos remote-név, amelyet kézzel adsz hozzá |
| origin | fork esetén a saját forkod (a klónozás hozza létre) |
| compare across forks | PR, amelynek forrása egy másik repóban (a forkban) van |
| maintainer (karbantartó) | az eredeti repó írási joggal rendelkező gondozója, aki beolvaszthat |
| Sync fork | a fork ágának frissítése az eredetiből a GitHubon |
| collaborator | meghívott csapattag írási joggal; neki nem kell forkolnia |
| CONTRIBUTING.md / LICENSE | hozzájárulási szabályok / a kód felhasználási feltételei |
| good first issue | kezdő hozzájárulóknak ajánlott feladat címkéje |
git remote add upstream <eredeti URL>; origin = fork (push), upstream = eredeti (fetch).git push -u origin … → PR a forkból az eredetibe; beolvasztani a karbantartó tud.git pull, vagy git fetch upstream → git merge upstream/main → git push origin main.A következő fejezetben megnézzük, hogyan szervezi a munkát egy csapat a GitHubon: issues, címkék, mérföldkövek és a Projects tábla.