Kako koristiti GitHub na poslu kao profesionalac

Početna » piton » Kako koristiti GitHub na poslu kao profesionalac

Učenje Gita i GitHuba na vlastitom projektu je odličan prvi korak, ali rad na isti način u profesionalnom okruženju brzo će naići na ograničenja: neurednu historiju, bolna spajanja i nikakvu vidljivost za vaš tim. Dobra vijest je da uz nekoliko konkretnih navika možete pretvoriti GitHub u centralni nervni sistem vašeg svakodnevnog rada, bez obzira da li programirate sami ili unutar velike inženjerske organizacije.

Ovaj vodič vas vodi kroz to kako se Git i GitHub obično koriste u stvarnim timovima.od strategije grana, dnevnih rutina komandi i discipline zahtjeva za povlačenjem, do problema, oznaka, projekata, pa čak i alata za produktivnost koji se nalaze na vrhu GitHuba. Također ćemo obraditi kako sigurno sarađivati ​​bez "lomljenja" repozitorija i kako strukturirati svoj račun i repozitorije tako da vaš profil već izgleda profesionalno.

Od ličnog skladišta igračaka do profesionalnog načina razmišljanja o toku rada

Kada ste jedina osoba koja vrši commit (potvrdu) u malom repozitoriju, primamljivo je samo dodati, commitovati i pustiti sve na glavni server.To funkcioniše za brze eksperimente, ali profesionalnim timovima je potrebna ponovljivost, sljedivost i saradnja. To znači jasne grane, male fokusirane commit-ove, opisne poruke i pregled koda kao zadanu putanju do main-a.

Zamislite Git kao mehanizam, a GitHub kao sloj za saradnju na vrhu.Git prati promjene datoteka lokalno na vašem računaru; GitHub hostira udaljene repozitorije, obrađuje zahtjeve za povlačenjem, probleme, dozvole, diskusije, automatizacije i integracije s alatima poput CI, chata i sistema za implementaciju. Zreli tok rada koristi obje strane: solidnu Git higijenu lokalno i strukturiranu saradnju na GitHub-u.

Čak i ako radite sami na sporednom projektu, i dalje se možete ponašati kao timKoristite grane funkcija, otvarajte zahtjeve za povlačenjem za vlastiti rad, dokumentirajte sve u README datoteci, pratite greške s problemima i označavajte izdanja. Ovo vas ne samo priprema za profesionalno okruženje, već i olakšava otklanjanje grešaka, vraćanje na prethodno stanje i uključivanje budućih saradnika.

Dizajniranje repozitorija kao profesionalac

Profesionalno korištenje GitHub-a počinje s načinom na koji dizajnirate i odvajate repozitorijeRazličite organizacije strukturiraju svoj rad na različite načine, ali postoji nekoliko uobičajenih obrazaca koji se pojavljuju iznova i iznova.

Repozitoriji proizvoda Koriste ih kompanije koje prate kod i poslovne metrike vezane za određene proizvode. Ovi repozitorijumi obično sadrže glavnu bazu koda, dokumentaciju, kontrolne ploče o ispravnosti i planove razvoja za taj proizvod. Oni postaju jedini izvor istine za sve što je vezano za tu liniju proizvoda.

Repozitoriji projekata su korisni kada radite na kratkotrajnim inicijativama, klijentskim projektima ili konsultantskim angažmanima. Sav relevantni kod, dokumentacija i informacije o statusu za taj angažman nalaze se u jednom repozitoriju, što olakšava premještanje ljudi na osnovu vještina i kapaciteta.

Repozitoriji tima služe kao središte za grupe koje posjeduju više kodnih baza. Na primjer, tim za razvojne alate može imati mnogo repozitorija za različite biblioteke ili usluge; namjenski timski repozitorij može centralizirati planiranje, probleme, dizajnersku dokumentaciju i odluke koje se odnose na te kodne baze.

Lični repozitoriji savršeni su za praćenje vlastitih zadataka, bilješki o učenju i eksperimenata. Možete ih zadržati privatnima kao ličnu bazu znanja ili ih otvoriti i pozvati saradnike da vam se pridruže na hobi projektima ili serijama učenja.

Također možete namjerno podijeliti repozitorije na osnovu potreba pristupaNeki timovi čuvaju izvorni kod u jednom repozitoriju i koriste zaseban "meta" repozitorij isključivo za planiranje: problema, diskusija, arhitektonskih odluka, RFC-ova. Ovo može pojednostaviti dozvole kada ne bi svi trebali vidjeti izvorni kod.

Osnovna struktura: README, DOPRINOS i predlošci

Svaki profesionalni repozitorij trebao bi započeti sa snažnom README datotekom.Ovo su ulazna vrata vašeg projekta: predstavite cilj repozitorija, kako započeti, kako lokalno pokrenuti projekat, kako doprinijeti i kako kontaktirati održavatelje. Tretirajte README datoteku kao živu dokumentaciju, a ne kao jednokratnu formalnost.

DOPRINOSNA datoteka formalizira kako očekujete da će ljudi komunicirati s projektomOvdje možete objasniti kako prijaviti grešku, kako zatražiti novu funkciju, koje standarde kodiranja slijediti, kako strukturirati grane i commitove, te kako izgleda proces pregleda. Ovo smanjuje trenje za nove članove i osigurava konzistentnost doprinosa.

Predlošci i obrasci problema su još jedno veliko unapređenje za timske tokove rada.Kada znate tipične vrste problema koje dobijate (greške, zahtjevi za funkcijama, velike inicijative, praćenje izdanja itd.), možete kreirati predloške koji unaprijed popunjavaju odjeljke poput „koraka za reprodukciju“, „očekivanog ponašanja“, „kriterijuma prihvatanja“ ili „uticaja“. Ovo održava dolazne probleme bogatim informacijama i olakšava trijažu.

Podproblemi i liste zadataka vam omogućavaju da razložite obimne zadatke na manje upravljive dijeloveMožete kreirati problem najvišeg nivoa za veliki projekat ili epsku temu, a zatim referencirati manje probleme kao podzadatke ili kućice u Markdown listi zadataka. GitHub može automatski ažurirati traku napretka kako se povezani problemi zatvaraju, dajući svima brz pregled statusa.

Oznake i vrste problema donose zajednički jezik vašem planiranjuUobičajeni tipovi uključuju „greška“, „funkcija“, „zadatak“, ali možete dodati i oznake domene poput „frontend“, „backend“, „performanse“ ili oznake stanja poput „blokirano“, „potreban dizajn“, „spremno za pregled“. Nakon što su oznake postavljene, možete filtrirati i pretraživati ​​probleme i zahtjeve za povlačenjem prema oznaci, što je ključno u velikim razmjerima.

Strategije grananja koje održavaju glavni proces stabilnim

Dobra strategija grananja je osnova sigurnog korištenja Gita na poslu.Definiše gdje razvijate funkcije, kako ispravljate hitne greške i kako kod na kraju stiže do produkcije bez haosa.

Jedan popularan model je Git FlowU ovom pristupu, zadržavate dugovječnu glavnu granu koja predstavlja produkciju i dugovječnu razvojnu granu za integraciju. Grane za funkcije se kreiraju iz razvojne grane i spajaju se nazad u nju kada su spremne. Grane za izdanje se izdvajaju iz razvojne grane kada pripremate novu verziju, a grane za hitne ispravke dolaze direktno iz glavne grane kako bi se riješili problemi u produkciji, a zatim se spajaju i u glavnu i u razvojnu granu.

GitHub Flow je jednostavnija, moderna alternativa koju mnogi timovi preferirajuOvdje, main uvijek odražava kod koji se može implementirati. Za bilo kakvu promjenu, kreirate kratkotrajnu granu s main-a, radite na svojoj funkciji ili ispravci, otvarate zahtjev za povlačenjem, primate pregled, a zatim se vraćate u main. Cjevovodi implementacije obično se automatski pokreću iz main-a. Ovaj model potiče male, česte promjene.

Pored tih modela, konvencije imenovanja olakšavaju životTimovi često dodaju prefiks granama na osnovu vrste posla: „feat/“ za nove funkcije, „fix/“ za ispravke grešaka, „refactor/“ za nefunkcionalna čišćenja, „chore/“ za zadatke održavanja i „hotfix/“ za hitne produkcijske ispravke. Grana poput „feat/share-fundraiser-buttons“ odmah govori drugima šta radite.

Koji god model da odaberete, jedno zlatno pravilo je gotovo univerzalnoNe prebacujte direktno na glavni kod osim ako se ne radi o eksplicitno odobrenoj hitnoj ispravci. Sve ostalo treba da teče kroz feature grane i pull request-ove kako bi pregled, testovi i provjere imali priliku da se izvrše prije nego što kod stigne u produkciju.

Dnevna Git rutina koja izbjegava 95% problema sa spajanjem

Većina konflikata spajanja i momenata tipa "ko je probio glavni sistem?" dolazi od ljudi koji rade na zastarjelim granama.Jednostavna, disciplinovana dnevna rutina dramatično smanjuje tu bol: održavajte svoju granu ponovo baziranom na najnovijoj glavnoj grani i često je sinhronizujte.

Visokoučinkoviti uzorak izgleda ovakoSačuvajte promjene koje su u toku, preuzmite glavnu datoteku sa rebase-om, a zatim ponovo primijenite svoj rad na vrh. Konkretno, pokrećete stash naredbu sa kratkom porukom, vršite rebase pull iz originalne glavne datoteke, a zatim izbacujete svoju stash datoteku tako da se vaše promjene nalaze na vrhu najnovije glavne historije.

Timovi često primjenjuju ritual kao što je „sakrij, povuci – ponovo baziraj, sakrij, iskoči“ u ključnim trenucima: prvo ujutro, prije početka bilo kojeg novog zadatka, odmah nakon što neko najavi hitnu ispravku i uvijek prije objavljivanja vlastitih commit-ova. Slijeđenje ovog jednostavnog pravila može eliminirati veliku većinu konflikata prije nego što se dogode.

Radi praktičnosti, mnogi inženjeri kreiraju alias ljuske za sinhronizaciju odjednomNa primjer, alias pod nazivom „sync“ može pohraniti vaš rad s oznakom „automatskog spremanja“ koja uključuje trenutno vrijeme, izvršiti ponovno povlačenje baze iz glavne grane, a zatim izvući spremljenu granu. S tim u konfiguraciji vaše ljuske, tipkanje „sync“ održava vašu granu ažurnom gotovo bez ikakvog napora.

Nakon što je vaša lokalna podružnica ažurirana, osnovna petlja od šest naredbi pokriva većinu svakodnevnog posla.Sačuvaj, povuci sa rebase-om, popuni, dodaj promjene, potvrdi (commit) sa značajnom porukom i pošalji na udaljenu granu. Odatle otvori ili ažuriraj svoj zahtjev za povlačenjem i pusti CI i recenzente da obave svoj posao.

Pisanje commitova kao profesionalac

U profesionalnim timovima, commit poruke nisu nasumični komentari; one su alat za komunikaciju i osnova za automatizaciju.Dobro strukturirane izmjene (commit) olakšavaju generiranje dnevnika promjena, razumijevanje historije i otklanjanje grešaka.

Mnogi timovi usvajaju konvencionalne commite ili sličan standard.To znači da svaki commit počinje tipom (kao što su „feat“, „fix“, „docs“, „style“, „refactor“, „perf“, „test“, „chore“), opcionalno opsegom u zagradama, a zatim kratkim opisom. Na primjer, „feat: dodaj kratki link za prikupljanje sredstava“ ili „fix: spriječi negativne iznose donacija“.

Dobre commit poruke su kratke, ali specifične„ispravka greške“ je beskorisna za šest mjeseci; „ispravka: obrada praznog polja za e-poštu u kontakt formi“ je i dalje razumljiva godinu dana kasnije. Kada je potrebno, detaljnije objašnjenje može se nalaziti u proširenom opisu ispod naslova.

U GitHub-ovom web editoru, vidjet ćete dva polja prilikom commit-a.: kratka poruka o commitu i opcionalni prošireni opis. Prvi red neka bude koncizan i koristite veliko tekstualno područje za pružanje konteksta kada promjena nije trivijalna, dotiče se više područja ili zahtijeva objašnjenje kompromisa.

Kada radite lokalno, izgradite naviku izvršavanja logičkih jedinica radaTo znači grupiranje povezanih promjena i izbjegavanje masovnih commitova tipa "promijenilo je sve". Ovo znatno olakšava pregled koda, analizu okrivljavanja i vraćanje prethodnih promjena.

Rješavanje sukoba i očuvanje čiste historije

Čak i sa jakim navikama, povremeno ćete se suočiti sa konfliktima spajanja ili neuspjesima prilikom popunjavanja skladišta.Znati kako ih mirno riješiti dio je profesionalnog korištenja Gita.

Kada pop ili spajanje skladišta rezultira konfliktima, Git označava pogođene datoteke markerima konflikta.Ovi markeri pokazuju verziju iz vaše grane i verziju iz grane u koju se spajate, odvojene jasnim razdjelnicima. Morate ručno otvoriti te datoteke, odlučiti kako kombinirati ili birati između promjena, a zatim ukloniti markere.

Nakon uređivanja radi rješavanja konflikta, pripremate ispravljene datoteke i kreirate novi commit. što predstavlja rješenje. U GitHub-ovom interfejsu, neke konflikte možete riješiti i direktno u pregledniku uređivanjem datoteke u prikazu konflikta i označavanjem kao riješenog prije spajanja.

Što se tiče čistoće historije, uobičajeni obrazac je lokalno rebaziranje, ali spajanje putem pull requesta na GitHub-u.Rebase održava vašu lokalnu historiju grana linearnom i lakom za praćenje, dok merge commit-ovi na GitHub-u čuvaju činjenicu da pull request predstavlja zaseban dio posla. Mnogi timovi biraju "Kreiraj merge commit" kao zadanu opciju prilikom popunjavanja pull requesta.

Prilikom spajanja zahtjeva za povlačenjem, neki timovi preferiraju "squash and merge" (kombinaciju i spajanje)., koji kombinuje sve commit-ove iz grane u jedan commit na glavnoj grani. Ovo održava glavnu historiju vrlo urednom, ali gubi se interna detaljna historija te feature grane. Drugi koriste "rebase and merge" za potpuno linearnu historiju, ali ovo zahtijeva disciplinu kako bi se izbjeglo prepisivanje dijeljene historije.

Problemi, diskusije i svakodnevna komunikacija

Problemi na GitHubu su mnogo više od inboxa s greškama; oni su vaša primarna jedinica planiranja i komunikacije.Možete ih koristiti za praćenje nedostataka, funkcija, rada na performansama, velikih inicijativa i kontrolnih lista za izdavanje.

Velike inicijative često imaju problem na najvišem nivou koji je povezan s mnogim manjim inicijativama.Ovo stvara hijerarhiju u kojoj roditeljski problem opisuje opći cilj i kontekst, a podproblemi obuhvataju konkretne zadatke. Podproblemi i liste zadataka vam pomažu da izrazite zavisnosti i pratite napredak ka većem cilju.

Oznake daju problemima značenje na prvi pogledNa primjer, probleme možete označiti prema vrsti („greška“, „funkcija“, „zadatak“), području („frontend“, „API“, „devops“), prioritetu ili statusu. Kombiniranje oznaka u filterima omogućava vam da odgovorite na pitanja poput „prikaži mi sve otvorene greške na frontendu“ ili „sav planirani rad vezan za performanse za ovaj kvartal“.

GitHub diskusije dopunjuju probleme tako što organizuju otvorene razgovoreIako su problemi odlični za specifične radne stavke, diskusije su bolje za brainstorming, povratne informacije i teme iz različitih repozitorija koje se ne povezuju uredno s jednom promjenom koda. Timovi ih koriste za preglede dizajna, debate o arhitekturi i pitanja i odgovore u zajednici.

Profesionalno, saigrači često daju dnevna ili sedmična ažuriranja putem komentara o problemima.Za veliki problem sa funkcijom i više saradnika, svaka osoba može ostavljati periodične komentare u kojima dijeli šta je završila, šta je blokirano i šta je sljedeće. Ovo zamjenjuje bučne niti razgovora i povezuje dnevnik rada sa stvarnim zadatkom.

Oznake, zavisnosti i projekti za stvarno planiranje

Kako vaš tim raste, planiranje i praćenje više repozitorija postaje ključnoGitHub-ove oznake i funkcije projekata pružaju moćno, ali lagano upravljanje projektima pored vaših problema i zahtjeva za povlačenjem.

Oznake, kao što je spomenuto, osnovni su način kategorizacije radaPored samo grešaka i funkcija, možete dodati oznake za prekretnice, poslovne ciljeve ili vertikale proizvoda. Primjena konzistentnih oznaka u svim repozitorijima omogućava menadžerima i potencijalnim klijentima da ispituju rad cijele organizacije po oznaci.

Zavisnosti problema vam pomažu da modelirate šta blokira štaKada označite problem kao "blokiran" od strane drugog ili naznačite da "blokira" druge, eksplicitno otkrivate skrivene zavisnosti. Ova vidljivost pomaže timovima da izbjegnu uska grla, daju prioritet deblokiranju posla i objasne kašnjenja zainteresovanim stranama bez haosa.

GitHub projekti djeluju kao prilagodljive proračunske tablice čvrsto integrirane s vašim kodomMožete kreirati projektne ploče za tim, proizvod, kvartalni plan razvoja ili međusektorsku inicijativu. Svaki projekat može automatski prikupiti probleme i zahtjeve za povlačenjem koji odgovaraju određenim filterima, te ostaje ažuriran kako se stanje stavki mijenja.

Prikazi u projektima vam omogućavaju da prelazite između rasporeda tabele, ploče i plana putaPrikaz tabele je odličan za liste koje se mogu sortirati i filtrirati; prikaz ploče se ponaša kao Kanban ploča sa kolonama kao što su „Zadaci“, „U toku“ i „Završeno“; a prikaz plana rada pomaže u vizualizaciji rada tokom vremena. Možete prilagoditi polja, grupisanja i filtere kako bi odgovarali načinu rada vašeg tima.

Korištenje GitHub Copilota i chata za razumijevanje složenih problema

Kada se pridružite nepoznatom projektu ili se suočite s dugotrajnim problemom, preopterećenje kontekstom je pravi problem.GitHub Copilot Chat može ubrzati proces uvođenja u sistem tako što će sumirati probleme, komentare i kod.

Sa bilo koje GitHub stranice možete otvoriti Copilot Chat panel, započnite novi razgovor i zamolite ga da sažme glavne tačke problema ili objasni svoj cilj. Copilot može istaknuti ključne odluke, neriješena pitanja i obim posla, tako da ne morate ručno čitati desetine komentara.

Copilot je također koristan za dešifriranje tehničkih termina, uloga datoteka ili isječaka koda spomenutih u problemu.Možete pitati šta određena funkcija radi, zašto je određena konfiguracijska datoteka važna ili šta bi određena greška mogla značiti u kontekstu. Ovo smanjuje vrijeme koje provodite pretražujući dokumentaciju ili čitajući nepovezani kod.

Kada shvatite kontekst, Copilot vam može predložiti sljedeće korakeMožete pitati kako pristupiti ispravci greške, koje granične slučajeve uzeti u obzir za novu funkciju ili kako podijeliti posao na manje zadatke. To neće donositi odluke umjesto vas, ali može ponuditi korisne početne tačke koje možete usavršiti vlastitom procjenom.

Račun, profil i osnovni koncepti GitHuba

Imati uredan i informativan GitHub profil dio je „profesionalnog korištenja GitHub-a“.Nakon registracije, možete prilagoditi svoj profil, postaviti status i organizirati svoje repozitorije i zvjezdice kako bi posjetitelji brzo razumjeli ko ste i na čemu radite.

Vaša profilna stranica prikazuje grafikon vašeg doprinosa i istaknute repozitorijeUređivanjem profila možete postaviti svoje ime, biografiju, zamjenice, lokaciju, web stranicu i društvene veze. Možete čak kreirati i poseban repozitorij s istim imenom kao i vaše korisničko ime; njegov README će se prikazati kao personalizirana stranica profila.

Meni profila uključuje odjeljke za repozitorije, projekte, zvijezde, giste i sponzoreRepozitoriji prikazuju sve vaše baze koda, s filterima za vidljivost i jezik. Projekti prikazuju vaše table za planiranje. Zvjezdice služe kao sistem oznaka za repozitorije koje želite zapamtiti ili podržati. Gistovi su mini-repozitorij za male isječke koda ili bilješke, a odjeljak za sponzore prati koga podržavate ili ko vas finansijski podržava, ako ste dio GitHub programa za sponzore.

U postavkama konfigurirate sigurnost, izgled i integracije.Možete upravljati e-poštom i lozinkom, postaviti SSH ključeve, omogućiti dvofaktorsku autentifikaciju, podesiti obavještenja, upravljati tokenima za pristup i integrirati GitHub s vanjskim aplikacijama i uslugama. Postoje i odjeljci za Copilot, Codespaces i sigurnosne kontrole za vaše repozitorije.

Razumijevanje osnovnih Gitovih koncepata poput repozitorija, grana, commitova i tagova je ključnoRepozitorij je kontejner za datoteke i historiju vašeg projekta. Grane predstavljaju paralelne linije razvoja. Commiti su snimci promjena u određenim vremenskim tačkama. Oznake označavaju određene commite, često se koriste za verzije i izdanja.

Pravo kreiranje i konfigurisanje repozitorija

Kada kreirate novi repozitorij na GitHub-u, donosite nekoliko ključnih odluka: ko je vlasnik, kako se zove, da li je javni ili privatni i koje pomoćne datoteke uključiti.

Vlasnik možete biti vi lično ili organizacijaVlasnik repozitorija kontrolira dozvole, postavke i naplatu. Solo projekti se često nalaze pod ličnim računima, dok se timski projekti nalaze pod organizacijama kako bi se centralizovalo upravljanje i kontrola pristupa.

Imena repozitorija trebaju biti kratka, opisna i lako pamtljivaSažet naziv koji odražava svrhu projekta je bolji od dugog internog koda. Opcionalni opis daje dodatni kontekst kada ljudi pregledavaju ili pretražuju.

Vidljivost je važna za saradnju i intelektualno vlasništvoJavni repozitoriji su dostupni svima, što je odlično za projekte otvorenog koda i portfolije. Privatni repozitoriji ograničavaju pristup na pozvane saradnike, što je obično zadana postavka za komercijalni rad ili eksperimente koje niste spremni podijeliti.

Uključivanje README, .gitignore i licence prilikom kreiranja štedi glavobolje kasnijeREADME datoteka predstavlja projekat. .gitignore datoteka govori Gitu koje datoteke ili direktorije treba ignorirati (artefakte izgradnje, datoteke okruženja, logove itd.). Licenca eksplicitno navodi kako drugi mogu koristiti vaš kod; GitHub čak pruža i pomoćnu stranicu za odabir između popularnih licenci poput MIT, Apache ili GPL.

Lokalni rad s Gitom i sinhronizacija s GitHubom

Profesionalno korištenje GitHuba i dalje počinje iz komandne linije na vašem računaru.Git radi lokalno, a podatke šaljete i preuzimate na GitHub kao udaljeni izvor istine. Također možete koristiti GUI klijente ili IDE-ove poput Osnove razvoja u Visual Studiu, ali razumijevanje osnovnih komandi je neprocjenjivo.

Kloniranje repozitorija kreira lokalnu kopiju udaljenog projektaPosjetite repozitorij na GitHub-u, kliknite na dugme „Kod“, kopirajte URL i pokrenite naredbu klon u svom terminalu iz direktorija u kojem želite da se nalazi. Git preuzima sve praćene datoteke i historiju, dajući vam kompletnu lokalnu radnu kopiju.

Prije potvrde, konfigurirajte svoje Git korisničko ime i e-poštuOve vrijednosti se koriste za pripisivanje commit-ova vama i obično bi trebale odgovarati vašem GitHub računu. Možete ih postaviti globalno tako da svi vaši repozitoriji dijele isti identitet ili ih po potrebi prepisati za svaki repozitorijum pojedinačno.

Osnovni lokalni tok rada je: uređivanje datoteka, provjera statusa, promjene u fazi, potvrđivanje (commit), a zatim slanje (push)Provjera statusa pokazuje šta se promijenilo i koje datoteke su pripremljene za obradu (staged). Priprema (staged) sa naredbom add premješta datoteke u skup "spremno za commit". Naredba commit snima snimak s vašom porukom. Konačno, push šalje vaše lokalne commitove na udaljenu granu na GitHubu.

Povlačenje je pandan guranju; ono skida promjene sa daljinskog upravljača.Obično pokrećete pull prije početka rada kako bi vaša lokalna grana uključivala nedavne commit-ove svih ostalih. U timskim radnim procesima, često ćete koristiti pull s rebase-om kako biste održali čistu linearnu historiju kao što je ranije opisano.

Grane, zahtjevi za povlačenjem, forkovi i saradnja

Grane su način na koji izolujete posao kako ne biste prekinuli glavni server za sve ostale.Kada započnete novu funkciju ili ispravku greške, kreirate granu na relevantnoj bazi (često glavnoj), tamo obavljate svoj posao i spajate je tek kada je spremna i pregledana.

Na GitHub-u, pull request-ovi su put za pregled i spajanje promjena.Zahtjev za povlačenje (pull request) predstavlja prijedlog za spajanje jedne grane u drugu. Prikazuje razlike (diff), povezane commite, recenzente, provjere i diskusiju. Članovi tima mogu komentirati direktno, tražiti promjene ili odobravati.

Kada radite na tuđem projektu gdje nemate pristup za pisanje, obično se forkujete umjesto grananja.Forking kreira vašu vlastitu kopiju njihovog repozitorija pod vašim računom. Vi vršite promjene u svom forku, a zatim otvarate zahtjev za povlačenjem nazad u originalni repozitorij. GitHub prati ovaj odnos tako da možete sinhronizirati svoj fork s promjenama u uzvodnom dijelu tokom vremena.

Sinhronizacija forka osigurava da se ne udaljavate previše od izvornog projektaGitHub nudi opciju "Sync fork" koja povlači nove commit-ove iz originalnog repozitorija u vaš fork. To biste trebali učiniti prije početka novog rada kako biste smanjili konflikte.

Kao održavatelj, vaš zadatak prilikom primanja zahtjeva za povlačenjem je da ih pažljivo pregledate.Pregledate izmijenjene datoteke, pokrećete ili vjerujete automatiziranim testovima, raspravljate o kompromisima i spajate, tražite prilagodbe ili zatvarate zahtjev za povlačenjem ako nije prikladan. Spajanje se može izvršiti putem merge commit-a, squash-a ili rebase-a, ovisno o postavkama historije vašeg tima.

Oznake, izdanja i verzioniranje

Oznake i izdanja pretvaraju beskrajan tok commitova u smislene verzijeKada vaš proizvod dostigne stabilnu tačku koju želite isporučiti ili na koju se želite referencirati, označite odgovarajući commit identifikatorom verzije.

Oznake su nepromjenjivi pokazivači na određene commite (izmjene).Često prate semantičko verzioniranje kao što je v1.2.7 ili v2.0.0. Oznake možete kreirati putem Git naredbi ili direktno u GitHubu prilikom izrade verzije.

GitHub objavljuje wrap tagove s dodatnim metapodacima i resursimaKada kreirate izdanje, povezujete ga s oznakom i dodajete naslov i opis. Ovdje obično pišete dnevnik promjena koji ljudi mogu čitati: šta je novo, šta je ispravljeno, poznati problemi. Također možete priložiti binarne datoteke ili artefakte koje korisnici mogu preuzeti.

Zastavice predizdanja pomažu u razlikovanju stabilnih verzija od beta verzijaOznačavanje izdanja kao predizdanja signalizira da nije spremno za produkciju, što je korisno za rane testere ili interne zainteresovane strane. Kada se stekne visoka pouzdanost, možete objaviti puna izdanja bez te oznake.

U radnim procesima u stilu Git Flow-a, izdanja su također povezana s vašim modelom grananja.Grane za izdanje (Release) se kreiraju kada pripremate novu verziju, a kada se ponovo spoje u glavnu granu (main), obično se kreira oznaka koja označava produkcijsku verziju. Ovo pruža jasan revizorski trag o tome šta je kada objavljeno.

Spajanje svih ovih dijelova – čvrste strategije grananja, konzistentnih poruka o commit-ovima, disciplinovane sinhronizacije, bogatog korištenja zadataka, dobro strukturiranih projekata i promišljenog profila – transformiše GitHub od jednostavnog hosta koda u moćnu platformu za saradnju.Bez obzira da li ste mlađi programer koji se pridružuje svom prvom timu ili iskusni inženjer koji vodi složene inicijative, korištenje Gita i GitHuba na ove načine pomoći će vam da se brže krećete, smanjite konflikte i olakšate razumijevanje i održavanje vašeg rada tokom vremena.