Medtem ko imajo uporabniki Gita na voljo na desetine vodnikov za začetek, GitHub pa ponuja številne lastne vodnike, še vedno ni lahko najti zbirke koristnih nasvetov za razvijalce, ki želijo pametneje delati z Git in GitHub. To popravimo.
Za tiste, ki Gita ali GitHub-a ne poznate, boste v naslednjih odstavkih dobili dovolj ozadja za razumevanje nasvetov. Na koncu tega članka bomo našteli približno ducat koristnih virov.
Git je porazdeljeni sistem za nadzor različic, ki ga je prvotno napisal Linus Torvalds leta 2005 za in s pomočjo jedrske skupnosti Linux. Nisem tukaj, da bi vas prodal na Gitu, zato vam bom prizanesel, kako hiter in majhen ter prilagodljiv in priljubljen je, vendar morate vedeti, da ko klonirate repozitorij Git (na kratko »repo«) , celotno zgodovino različic dobite v svojem računalniku, ne le posnetek iz ene veje hkrati.
Git se je začel kot orodje ukazne vrstice, kar ustreza njegovemu izvoru v skupnosti jeder Linuxa. Če želite, lahko še vedno uporabljate ukazno vrstico Git, vendar vam ni treba. Če še posebej uporabljate GitHub kot gostitelja, lahko v Windows ali Mac uporabite brezplačni odjemalec GitHub Desktop. Po drugi strani pa bo ukazna vrstica Git delovala za katerega koli gostitelja in je vnaprej nameščena v večini sistemov Mac in Linux.
Samo vi se lahko odločite, ali vam je najbolj udobno uporabljati ukazno vrstico ali izvorni odjemalec z grafičnim uporabniškim vmesnikom. Če vam je všeč GUI, lahko poleg odjemalca GitHub (Windows in Mac) razmislite še o SourceTree (Windows in Mac, brezplačno), TortoiseGit (samo za Windows, brezplačno) in Gitbox (samo za Mac, 14,99 USD). Lahko pa uporabite urejevalnik ali IDE, ki interno podpira Git (glejte nasvet št. 11).
Nasvet Git / GitHub št. 1: Klonirajte skoraj vse
Na voljo je veliko zanimivih projektov iz GitHub in drugih javnih skladišč Git, ki jih lahko prosto klonirate v svoj računalnik. Zakaj bi to želeli storiti? Eden od razlogov je, da se naučite nekaj o slogu kodiranja, praksi in orodjih v jeziku, ki vas zanima, vključno s slogom komentiranja dnevnika zapisov (glejte nasvet št. 4). Drugi razlog je, da se naučimo, kako dani projekt uresničuje svoje cilje. Tretji razlog, če bi vam licenca to dovoljevala in je smiselna za vaše namene, bi bil vključitev projekta v vaše lastne napore ali izdelek. Mimogrede, dvakrat preverite licenco, da pozneje ne boste naleteli na težave s skladnostjo.
Opredelitev klon git s strani z navodili:
Klonira repozitorij v novo ustvarjeni imenik, ustvari veje za oddaljeno sledenje za vsako vejo v kloniranem repozitoriju (vidno z uporabo git podružnica -r) ter ustvari in preveri začetno vejo, ki je razcepljena iz trenutno aktivne veje kloniranega repozitorija.
Po klonu še ravnina git fetch brez argumentov bo posodobil vse veje oddaljenega sledenja in a git pull brez argumentov bo poleg tega združil oddaljeno glavno vejo v trenutno glavno vejo, če obstaja.
Git / GitHub nasvet št. 2: Pogosto povlecite
Eden najlažjih načinov, kako narediti nered z Gitom (in res s katerim koli sistemom za nadzor različic), je omogočiti datotekam, da se ne uskladijo. Če ti git pull pogosto boste posodabljali svojo kopijo repo in imeli boste možnost, da spremenite svojo kodo s spremembami drugih, medtem ko je združitev enostavno razumeti in izvesti - v idealnem primeru, ko je tako enostavno, da je to mogoče samodejno. Posledica tega nasveta je spremljanje stanja vašega projekta. Številni odjemalci Git vam samodejno prikažejo, kdaj morate posodobiti, da ostanete na tekočem.
Git / GitHub nasvet št. 3: zavežite se zgodaj in pogosto
Obveza je podrobna posodobitev projekta, ki vključuje eno ali več sprememb ene ali več datotek. Pomislite na to kot na zapis o zaključeni enoti dela, ki jo je mogoče uporabiti ali odstraniti iz projekta kot logično celoto. Zavežite vsako logično spremembo, ki jo dokončate, še preden jo preizkusite. Obveze veljajo samo za vaše lokalno skladišče. Za posledice tega nasveta glejte nasveti št. 4 in 5.
Opredelitev git commit s strani z navodili:
Shrani trenutno vsebino indeksa v novi objavi skupaj s sporočilom dnevnika uporabnika, ki opisuje spremembe.
Nasvet za Git / GitHub št. 4: Komentirajte svoje zaveze, tako kot bi drugi komentirali njihove
Obstaja 10 vrst kodirnikov: tisti, ki komentirajo svoje obveznosti, in tisti, ki jih ne. (Stara šala. Namig: Kakšno podlago uporabljam?)
Priznavam, da sem nalepka za dobra sporočila dnevnika zapisov. Svoje repozitorije sem nastavil tako, da zahtevajo sporočila za vsako objavo, znano pa mi je bilo, da pošiljam nadležna poznonočna sporočila, ko zaveže zemljišče z dnevniki po vrstnem redu »xx«. Če ste tisti razvijalec, ki meni, da bi (1) koda morala govoriti sama zase in (2) vrstni komentarji so bolj pomembni kot dnevniki sprememb, poskusite klonirati repozitorij, ki ga še niste videli, in identificirati nedavni prevzem, ki je morda povzročil zadnjo objavo, ne da bi prebral vso kodo. Kot lahko vidite, so natančni dnevniki zapisov dvojni plus.
Git / GitHub nasvet št. 5: Pritisnite, ko so spremembe preizkušene
Najhujša napaka, povezana z Gitom, o kateri sem kdaj imel srečo, se je zgodil, ko se je podjetje, ki je izvajalo zunanje izvajalce, preusmerilo s Subverzije, vendar svojih razvijalcev ni usposobilo za razliko med nadzorom distribuiranega vira in centraliziranim nadzorom virov. Približno mesec dni kasneje je projekt razvil čudne napake, ki jih nihče ni mogel izslediti. Na vsakodnevnih stand-up sestankih so razvijalci, odgovorni za področje aplikacije, ki se je neprimerno obnašala, protestirali: "To sem popravil pred dvema tednoma!" ali obtožite drugega razvijalca, da se ni potrudil vnesti sprememb, ki so jih tako skrbno preverili.
Sčasoma je nekdo ugotovil težavo in vse razvijalce naučil, kako in kdaj potisnite njihovi prevzemi: Skratka, kadarkoli se zaveze uspešno preizkusijo v lokalni gradnji. Nato je podjetje izvedlo dvodnevni fest spajanja, preden je lahko zgradilo in uvedlo posodobljeni integrirani izdelek.
Git / GitHub nasvet št. 6: Prosto vejte
Ena največjih prednosti, ki jih ima Git pred drugimi sistemi za nadzor različic, je ta, da združevanje običajno deluje dobro, vsaj deloma zato, ker Git samodejno izbere najboljšega skupnega prednika za združitev. Večina razvijalcev programske opreme mora pogosteje začeti ustvarjati veje v svojih projektih. To bi moralo biti rutinsko vsakodnevno dogajanje, ne pa predmet zaskrbljujočega strateškega srečanja. Verjetno je, da ko bo projekt podružnice končan, sprejet in pripravljen za prehod v glavni projekt, združitev ne bo povzročila nepremostljivih težav.
Vem, da je to treba nekoliko prilagoditi, še posebej, če ste že obstali v podjetju, ki s sistemom CVS nadzoruje izvorno kodo. Ampak poskusite. Veliko bolje je, kot da kupci po naključju vidijo nedokončano eksperimentalno kodo, ko je treba projekt trunk objaviti zaradi napake. (Ta članek dobro razlaga osnovno razvejanje in združevanje.)
Git / GitHub nasvet št. 7: Previdno združite
Medtem ko združitve z Gitom običajno dobro delujejo, če jih naredite brez razmišljanja, lahko občasno naletite na težave. Prvi korak je, da se prepričate, da nimate nobenih nepovezanih sprememb. Iz git merge stran z navodili:
Pred uporabo zunanjih sprememb bi morali svoje delo spraviti v dobro obliko in se zavezati lokalno, tako da v primeru konfliktov ne bo opustošeno. Poglej tudi git-stash.
Glej tudi nasvet št. 8.
Tudi če gre v času a git merge, niste napeti:
Če ste poskusili z združitvijo, ki je povzročila zapletene konflikte, in želite začeti znova, lahko obnovite s git merge —abort.
Nadaljnji ukaz za git merge je običajno git mergetool, ob predpostavki, da radi uporabljate GUI za združevanje. Če želite raje starošolsko metodo, lahko urejate datoteke v nasprotju z vašim najljubšim programskim urejevalnikom in popolnoma odstranite <<<<<<<, =======, in >>>>>>> vrstic, shranite popravljene datoteke in git add vsako datoteko, ki ste jo popravili.
Git / GitHub nasvet št. 8: Skrbite pred zamenjavo vej
Potek dela razvijalca programske opreme je redko linearen. Uporabniki imajo veliko okvare za prijavo napak, upravitelji imajo drznost, da dajo prednost vozovnicam, ki niso tiste, ki ste si jih izbrali za delo, vi pa si morda premislite, kaj želite storiti.
Tu ste, s tremi datotekami, izdanimi za izdajo, in četrto datoteko v spremenjenem, a nedelujočem stanju. (The git status vse to vam bo povedal, če se slučajno ne spomnite, kje ste bili.) Kar naenkrat morate v produkcijski različici odpraviti napako. Morate zamenjati veje vnaprej, vendar ne morete. Vaš delovni imenik je umazan in imate dve uri dela, ki ga ne želite izgubiti.
Enter git stash. Voilà! Zdaj imate vse spremembe shranjene v veji WIP (nedokončane obdelave) in iz čistega imenika lahko preklopite na produkcijsko vejo. Ko končate s tem, se preklopite nazaj, kjer ste bili git stash velja.
Nasvet za Git / GitHub št. 9: Uporabite sezname, da delite delčke in paste
GistHub-ovi "kodi" - delčki kode v skupni rabi - niso funkcija Git, vendar uporabljajo Git. Vsi seznami so skladišča Git, GitHub Gist pa omogoča enostavno njihovo skupno rabo. V Gistu lahko iščete javne sezname po temah, programskem jeziku, razčlenjenem statusu in stanju z zvezdico. Ustvarite lahko tudi skrivne sezname in jih delite po URL-jih.
Nasvet za Git / GitHub št. 10: Raziščite GitHub
Številni zanimivi odprtokodni projekti imajo skladišča na GitHubu. Explore GitHub ponuja brskalniški vmesnik za iskanje nekaterih od njih, večinoma pa je lažje v iskalno polje vnesti nekaj črk imena projekta in poiskati njegove repozicije. Na primer, vnesite jq ali nazaj ali ang najti tri glavne odprtokodne okvire JavaScript.
Nasvet Git / GitHub št. 11: Prispevajte k odprtokodnim projektom
Zakaj ne bi prispevali k njim, dokler brskate po odprtokodnih projektih? Ni tako težko, kot si morda mislite, in veliko se boste naučili. Na primer, lahko klonirate projekt jquery / jquery (jQuery Core) in brskate po README.MD. Na vrhu boste videli:
V duhu odprtokodne programske opreme jQuery vedno spodbuja prispevanje kode skupnosti. Za lažji začetek in preden začnete pisati kodo, temeljito preberite te pomembne smernice za prispevke ...
Temu sledijo tri povezave. Prvi od treh vas bo dokaj hitro začel. Vsak odprtokodni projekt načrta ne razloži tako jasno, vendar se vsi trudijo.
Razumevanje razlike med sodelovanjem in prevzemom obveznosti. Sodelujoči je podpisal zahtevane sporazume in dal projekt na razpolago. Oddajalec je pooblaščen, da dejansko preda predlagani prispevek v repozitorij projekta. Ker bo pri izvedbi preizkusa vašega prispevka prišlo do zamude in ne boste želeli vezati svoje glavne podružnice, morate pred pošiljanjem zahteve za vlečenje vnesti spremembe v drugo podružnico (glejte nasvet št. 6) (glejte nasvet št. . 16).
