Nors „Git“ vartotojai turi dešimtis pradžios vadovų, iš kurių galima rinktis, o „GitHub“ siūlo keletą savo vadovų, vis tiek nėra lengva rasti naudingų patarimų rinkinį kūrėjams, norintiems sumaniau dirbti su „Git“ ir „GitHub“. Pataisykime tai.
Tiems iš jūsų, kurie nėra susipažinę su „Git“ ar „GitHub“, kitos kelios pastraipos suteiks pakankamai informacijos, kad suprastumėte patarimus. Šio straipsnio pabaigoje pateiksime apie keliolika naudingų šaltinių.
„Git“ yra paskirstyta versijų valdymo sistema, kurią iš pradžių Linusas Torvaldsas parašė 2005 m. „Linux“ branduolio bendruomenei ir jai padedant. Aš nesu čia tam, kad parduočiau jus „Git“, todėl aš jums pasigailėsiu rašybos apie tai, kaip greitai, maži, lankstūs ir populiarūs, tačiau turėtumėte žinoti, kad klonuodami „Git“ saugyklą (trumpai „repo“) , jūs gaunate visą versijų istoriją savo kompiuteryje, o ne tik vienos šakos momentinę nuotrauką vienu metu.
„Git“ pradėjo veikti kaip komandinės eilutės įrankis, atitinkantis jo kilmę „Linux“ branduolio bendruomenėje. Jei norite, vis tiek galite naudoti „Git“ komandų eilutę, bet to neturite. Visų pirma, jei naudojate „GitHub“ kaip pagrindinį kompiuterį, galite naudoti nemokamą „GitHub Desktop“ klientą sistemoje „Windows“ arba „Mac“. Kita vertus, „Git“ komandų eilutė veiks bet kuriam pagrindiniam kompiuteriui ir yra iš anksto įdiegta daugumoje „Mac“ ir „Linux“ sistemų.
Tik jūs galite nuspręsti, ar jums patogiausia naudoti komandinę eilutę, ar savąjį klientą su grafine vartotojo sąsaja. Jei jums patinka GUI, galbūt norėsite apsvarstyti ne tik „GitHub“ klientą („Windows“ ir „Mac“), bet ir „SourceTree“ (nemokami „Windows“ ir „Mac“), „TortoiseGit“ (tik „Windows“, nemokami) ir „Gitbox“ (tik „Mac“, 14,99 USD). Arba galite naudoti redaktorių arba IDE, kuris palaiko „Git“ iš vidaus (žr. 11 patarimą).
„Git / GitHub“ patarimas Nr. 1: Klonuokite beveik viską
„GitHub“ ir kitose viešose „Git“ saugyklose galima rasti daug įdomių projektų, kuriuos galite laisvai klonuoti į savo kompiuterį. Kodėl norėtumėte tai daryti? Viena iš priežasčių yra išmokti ką nors sužinoti apie kodavimo stilių, praktiką ir įrankius dominančia kalba, įskaitant įsipareigojimų žurnalo komentavimo stilių (žr. 4 patarimą). Antra priežastis yra sužinoti, kaip konkretus projektas pasiekia savo tikslus. Trečia priežastis, jei licencijavimas jums tai leistų ir būtų prasmingas jūsų tikslams, būtų įtraukti projektą į savo veiklą ar produktą. Dar kartą patikrinkite licenciją, beje, kad vėliau nekiltų problemų dėl atitikties.
Apibrėžimas git klonas iš vadovo puslapio:
Klonuoja saugyklą į naujai sukurtą katalogą, sukuria nuotolinio stebėjimo šakas kiekvienam klonuotos saugyklos filialui (matomas naudojant gito šaka -r), sukuria ir patikrina pradinį filialą, kuris yra išsišakojęs iš šiuo metu aktyvaus klonuoto saugyklos filialo.
Po klono - lyguma git atnešti be argumentų atnaujins visas nuotolinio stebėjimo šakas ir a git traukti be argumentų, nuotolinis pagrindinis filialas bus sujungtas su dabartiniu pagrindiniu filialu, jei toks yra.
„Git / GitHub“ patarimas Nr. 2: dažnai traukite
Vienas iš paprasčiausių būdų padaryti netvarką sau su „Git“ (ir iš tikrųjų su bet kuria versijų valdymo sistema) yra leisti failams ištrinti iš sinchronizavimo. Jei tu git traukti dažnai atnaujinsite savo atpirkimo kopiją ir turėsite galimybę sujungti savo pakeistą kodą su kitų pakeitimais, o sujungimą lengva suprasti ir atlikti - idealiu atveju, kai tai taip lengva, kad tai galima padaryti automatiškai. Šio patarimo pasekmė yra stebėti jūsų projekto būseną. Daugelis „Git“ klientų automatiškai parodys, kada reikės atnaujinti, kad išliktumėte aktualūs.
„Git“ / „GitHub“ patarimas Nr. 3: įsipareigokite anksti ir dažnai
Įsipareigojimas yra išsamus projekto atnaujinimas, apimantis vieną ar daugiau vieno ar daugiau failų pakeitimų. Pagalvokite apie tai kaip apie atlikto darbo vieneto įrašą, kurį galima pritaikyti projektui arba pašalinti iš jo kaip loginę visumą. Atlikite visus atliktus loginius pakeitimus, net prieš juos išbandydami. Įsipareigojimai taikomi tik jūsų vietinei saugyklai. Žr. Šio patarimo pasekmes 4 ir 5 patarimuose.
Apibrėžimas git įsipareigoti iš vadovo puslapio:
Saugo dabartinį indekso turinį naujame įsipareigojime kartu su vartotojo žurnalo pranešimu, kuriame aprašomi pakeitimai.
„Git / GitHub“ patarimas Nr. 4: komentuokite savo įsipareigojimus taip, kaip norėtumėte, kad kiti komentuotų savo
Yra 10 koduotojų rūšių: tie, kurie komentuoja savo įsipareigojimus, ir tie, kurie to nedaro. (Senas pokštas. Užuomina: kokią bazę naudoju?)
Aš laisvai prisipažįstu esąs lipdukas, skirtas gerai atlikti žurnalo pranešimus. Aš sukūriau savo saugyklas, kad reikalautų pranešimų apie kiekvieną įsipareigojimą, ir man buvo žinoma, kad siunčiau susierzinusius vėlyvojo vakaro pranešimus, kai vykdau žemę su žurnalais „xx“ tvarka. Jei esate tas kūrėjas, kuris mano, kad (1) kodas turėtų kalbėti pats už save ir (2) tiesioginiai komentarai yra daug svarbesni nei pakeitimų žurnalai, pabandykite klonuoti dar nematytą saugyklą ir identifikuoti neseniai įvykdytas įsipareigojimas, dėl kurio galėjo atsirasti naujausias numeris, paskelbtas neperskaičius viso kodo. Kaip matote, tikslūs įsipareigojimų žurnalai yra dvigubai geri.
„Git / GitHub“ patarimas Nr. 5: spauskite, kai bus išbandyti jūsų pakeitimai
Blogiausia su manimi susijusi „Git“ klaida, apie kurią man yra tekę žinoti, nutiko, kai užsakomųjų paslaugų įmonė persijungė iš „Subversion“, tačiau nemokė savo kūrėjų apie skirtumą tarp paskirstyto šaltinio valdymo ir centralizuoto šaltinio valdymo. Maždaug po mėnesio projekte atsirado keistų klaidų, kurių niekas, regis, neatsekė. Kasdieniniuose „stand-up“ susitikimuose kūrėjai, atsakingi už netinkamai veikiančią programos sritį, protestuos: „Aš tai sutvarkiau prieš dvi savaites!“ arba apkaltinti kitą kūrėją, kad jis nesivargintų traukti taip atidžiai patikrintus pakeitimus.
Galų gale kažkas nustatė problemą ir išmokė visus kūrėjus, kaip ir kada stumti jų įsipareigojimai: Trumpai tariant, kiekvieną kartą, kai įsipareigojama, sėkmingai išbandoma vietinėje versijoje. Tada įmonė, prieš sukurdama atnaujintą, integruotą produktą, sukūrė dviejų dienų trukmės sujungimo šventę.
„Git / GitHub“ patarimas Nr. 6: Filialas laisvai
Vienas iš didžiausių „Git“ pranašumų, palyginti su kai kuriomis kitomis versijų valdymo sistemomis, yra tai, kad sujungimas paprastai veikia gerai, bent jau iš dalies dėl to, kad „Git“ automatiškai pasirenka geriausią bendrą protėvį, kurį naudos sujungimui. Daugumai programinės įrangos kūrėjų savo projektuose reikia pradėti kurti filialus dažniau. Tai turėtų būti įprastas kasdienis įvykis, o ne įtartino visų rankų strateginio susitikimo tema. Tikimybė yra ta, kad kai filialo projektas bus baigtas, priimtas ir pasirengęs pereiti prie pagrindinio projekto, sujungimas nekels neįveikiamų problemų.
Žinau, kad reikia šiek tiek pakoreguoti, ypač jei esate įstrigę įmonėje, kuri kontroliuoja šaltinio kodą naudodama CVS. Bet pabandykite. Tai yra daug geriau, nei klientai netyčia pamatys jūsų neužbaigtą eksperimentinį kodą, kai bagažinės projektą reikia paskelbti dėl lūžiančios klaidos. (Šiame straipsnyje gerai paaiškinamas pagrindinis šakojimasis ir sujungimas.)
„Git / GitHub“ patarimas Nr. 7: atsargiai sujunkite
Nors susiliejimas su „Git“ paprastai veikia gerai, jei tai darote negalvodamas, kartais galite susidurti su sunkumais. Pirmas žingsnis - įsitikinkite, kad neturite neįvykdytų pakeitimų. Nuo susilieti vadovas puslapis:
Prieš taikydami išorinius pokyčius, turėtumėte gauti gerą savo darbo formą ir įsipareigoti vietoje, taigi, jei kils konfliktų, jis nebus apiplėštas. Taip pat žiūrėkite git-atlicinti.
Taip pat žiūrėkite patarimą Nr. 8.
Net jei visa tai eina į pietus a susilieti, jūs neprarandate:
Jei bandėte sujungti, dėl kurio kilo sudėtingi konfliktai, ir norite pradėti iš naujo, galite atsigauti git sulieti —abortas.
Tolesnė komanda susilieti paprastai yra git mergetool, darant prielaidą, kad jums patinka naudoti GUI sujungiant. Jei pageidaujate senosios mokyklos metodo, galite redaguoti failus, prieštaraujančius jūsų mėgstamam programavimo redaktoriui, visiškai pašalinti <<<<<<<, =======ir >>>>>>> eilučių, išsaugokite pataisytus failus ir git pridėti kiekvieną failą, kurį pataisėte.
„Git“ / „GitHub“ patarimas Nr. 8: Prieš keisdami šakas, paslėpkite
Programinės įrangos kūrėjo darbo eiga retai būna tiesinė. Vartotojai gali pranešti apie klaidas, vadybininkai įžūliai teikia pirmenybę bilietams, išskyrus tuos, kuriuos pasirinkote dirbti, ir jūs pats galite apsigalvoti, ką norite daryti.
Štai, jūs turite tris failus, skirtus išleisti, ir ketvirtą failą pakeista, bet neveikiančia būsena. ( git statusas komanda jums visa tai pasakys, jei neatsitiksite, kur buvote.) Staiga jums reikia ištaisyti gamybinės versijos klaidą. Pronto reikia pakeisti šakomis, bet negalima. Jūsų darbo katalogas yra nešvarus, o jūs turite dvi valandas darbo, kurio nenorite prarasti.
Įveskite git paslėpti. Voilà! Dabar visi pakeitimai yra saugomi WIP (nebaigtų darbų) skyriuje ir galite pereiti į gamybos skyrių iš savo švaraus katalogo. Kai baigsite tai, perjunkite atgal į vietą, kurioje buvote taikoma git atlicināt.
„Git“ / „GitHub“ patarimas Nr. 9: naudokitės susirašinėjimais, kad galėtumėte dalytis fragmentais ir pastomis
„GitHub“ „bendrieji“ kodai - bendrinami kodo fragmentai - nėra „Git“ funkcija, tačiau jie naudoja „Git“. Visi esmė yra „Git“ saugyklos, o „GitHub Gist“ leidžia lengvai jais dalytis. „Gist“ galite ieškoti viešų sąrašų pagal temą, programavimo kalbą, išsišakojimo būseną ir žvaigždute pažymėtą būseną. Taip pat galite sukurti slaptus sąrašus ir bendrinti juos pagal URL.
„Git / GitHub“ patarimas Nr. 10: tyrinėkite „GitHub“
Daug įdomių atvirojo kodo projektų turi „GitHub“ saugyklas. Naršykite „GitHub“ teikia naršymo sąsają, kad galėtumėte rasti kai kuriuos iš jų, tačiau dažniausiai paieškos laukelyje lengviau įvesti kelias projekto pavadinimo raides, kad būtų galima rasti jo repozitus. Pavyzdžiui, įveskite jq arba atgal arba ang rasti tris pagrindines atvirojo kodo „JavaScript“ sistemas.
„Git / GitHub“ patarimas Nr. 11: prisidėkite prie atvirojo kodo projektų
Kol naršote atvirojo kodo projektus, kodėl neprisidedate prie jų? Tai nėra taip sunku, kaip jūs manote, ir jūs daug ko sužinosite. Pavyzdžiui, galite klonuoti „jquery / jquery“ („jQuery Core“) projektą ir naršyti po README.MD. Netoli viršaus pamatysite:
Atvirojo kodo programinės įrangos kūrimo dvasia „jQuery“ visada skatina bendruomenės kodo įnašą. Kad galėtumėte lengviau pradėti ir prieš pradėdami rašyti kodą, būtinai atidžiai perskaitykite šias svarbias įnašo gaires ...
Po to seka trys nuorodos. Pirmasis iš trijų pradėsite gana greitai. Ne kiekvienas atvirojo kodo projektas taip aiškiai pateikia planą, tačiau visi jie stengiasi.
Supraskite skirtumą tarp buvimo aukotoju ir įsipareigotoju. Bendradarbis pasirašė reikiamus susitarimus ir padarė prieigą prie projekto. Įpareigotojas yra įgalintas faktiškai įnešti įnašą į projekto saugyklą. Kadangi vėluoja, kol įsipareigojantis asmuo patikrins jūsų indėlį ir jūs nenorėsite susieti savo pagrindinio filialo, prieš išsiųsdami užklausą (žr. Patarimą Nr. 6) turėtumėte atlikti pakeitimus kitame filiale (žr. Patarimą Nr. 6). 16).
