Dotaz: Github - jak se pripojit k projektu

[Martin Divis]

Ahoj vyvojari, nejaky cas programuji v C a nasel jsem v tom zalibeni, rad bych se pripojil k nejakemu OS projektu, zacal jsem se tedy ucit git, jelikoz par peknych projektu jsem nasel na sluzbe gitbub.

Neni mi ale uplne jasne jak github funguje, naklonuji si projekt pomoci git clone k sobe, zacnu provadet upravy sw a commitovat je do sveho lokalniho repositare, jak nasledne dostanu tyto zmeny do hlavni vetve? (musim zaslat patch autorovi emailem? nejak mi neni jasne zda-li mohu delat git push/pull apod operace).

A take bych se rad zeptal zda-li lze vysvetlit jak funguje to slucovani (merge), nedokazu si predstavit  jak autor puvodniho projektu zajistuje zaclenovani patchu, jak zajisti, ze patch ktery zasilam upravuje prave tuto konkretni verzi souboru (co kdyz ji nekdo zmenil behem zaslani patche?).

Diky vsem za ochotu, jsem zacatecnik.

---

---

Odpovědi

[xkucf03]

Že by ti dal autor programu jen tak práva na push, se dá celkem vyloučit – určitě ti je nedá jen tak, že bys mu napsal, že chceš přispívat (a posílat změny mailem je hloupé a nepohodlné). Proto se, aspoň zpočátku, používá scénář „správce integrace“ – změny budeš dělat do svého úložiště a když se budou autorovi programu líbit, stáhne si je od tebe a začlení. K úložišti na tvém počítači se jen tak nedostane, takže potřebuješ nějaké veřejně dostupné úložiště – třeba u tebe na serveru – ale úplně nejjednodušší bude, když uděláš na tom GitHubu fork toho programu, vlastní větev, a do ní budeš commitovat resp. pullovat ty změny – a pak akorát pošleš autorovi programu požadavek na začlenění tvých změn.

[chrono]

a posílat změny mailem je hloupé a nepohodlné

Nepohodlné pre koho?

[dustin]

Souhlasím, maily generované přímo gitem se běžně používají pro předávaní patchů správcům subsystémů linuxu. Hned vidí popis commitu, provedené změny, je to OK a praktické. Nevyžaduje to tolik mergů, správce si patch commitne rovnou do své větve, historie je lineárnější.

Samozřejmě v rámci užší pracovní skupiny jsou lepší méně pracné varianty.

[Jirka Keresteš]

kazdy projekt muze mit svoje vlastni zvyklosti, uplne idealni je zeptat se na dev listu daneho projektu. Nicmene pokud se ti ptat nechce, tak asi nic nezkazis nasledujicim postupem:

• na strance projektu na githubu klikni na "Fork" a potvrd, ze se to ma forktnou k tobe - to vytvori svoji vlatni kopii (fork) daneho projektu, kam mas pravo commitovat
• naklonuj si svou kopii projektu z githubu (pres git@github.com:...., abys tam pozdeji mohl odeslat zmeny)
• proved lokane zmeni, komitni do lokalniho repozitare a pote, co jsou zmeny hotove, je odesli do te sve kopie na githubu
• pote na strance kopie projektu na githubu klikni na "Pull Request" a potvrd, ze chces odelat patch - toto na strance puvodniho projektu (upstream projektu) vytvori pozadavek na zacleneni tebou provedenych zmen do puvodniho projektu
• autor/autori si pak obyvkle patch prohlednou, rovnou akceptuji nebo uporozni, co je treba opravit. Pokud je delsi cas pull request bez komentaru a neni akceptovan, je dobre napsat na dev list daneho projektu.

Par dobry praktik:

• pred odeslanim zmen je dobre aktualizovat projekt (stahnout pripadne zmeny z upstream projektu) a svoje zmeny zaclenit az nakonec pomoci git rebase (viz napr. dotaz v poradne zde)
• zmeny nedelat do master vetve, ale pro kadnou zmenu vytvorit vlastni vetev. Pull request pak posilat z teto vetve
• pokud ma projekt nejaky issue tracker (treba Bugzilla nebo Jira), je dobre vytvorit prvne issue v tom tracking systemu a pak jeji cislo uvadet do vsech commitu (usnadnuje to orientaci, pripadne backportovani a navic nektery projekty maji git integrovany s tracking systemem, takze k danym issue automaticky pridavaji linky na commity, ktere jsou s danou issue svazane)

Jinak vrele doporucuji si precit neco o gitu, napr. v cestine dostupnou knihu Pro Git

[Martin Divis]

Dobry den, dekuji mnohokrat, presne takove informace jsem hledal, otevreny software se mi myslenkou velmi libi, bohuzel mi prijde vcelku slozite zacit se v nem orientovat nejspise proto, ze kazdy projekt ma svoji vlastni "stabni" kulturu, jeste jednou diky.

Napr. clanek na tema jak zacit spolupracovat na nejakem projektu si myslim byl zajimavy i pro ostatni.

Diky Martin, jdu se s tim porvat vlastni fork jsem uz udelal, lokalni repo mam u sebe, knihu Gitu uz mam a ctu ji i kdyz abych pravdu rekl, tak prace s vetvemi projektu a slucovanim je divocina a moc to zatim nechapu, doufam, ze se tim prokousu.

[Kit]

"Štábní kulturu" dodržovat nemusíš, ale může to způsobit odtržení od původního projektu. Ovšem pokud ta tvá odnož bude lepší, časem se patche od ostatních přesunou z původního projektu na ten tvůj.

Jednou mi jeden program v distribuci házel nesmyslné výsledky. Když jsem se podíval do zdrojáku, tak jsem se zhrozil. Když jsem ho opravil, zbyl z původního programu jediný řádek. Se jménem původního autora

Tím chci říct, že všichni jsme lidé. Někdo dostane nápad, jiný ho zrealizuje, další ho opraví a opět další ho udržují a dokumentují. V kterékoli fázi může dojít nejen ke změně štábní kultury, ale i k úplné refaktorizaci. Když to budeš dělat ve vlastním forku, upravuj to tak, jak si myslíš, že by to mělo být.