27 osnovnih savjeta za korisnike Gita i GitHuba

Iako korisnici Gita imaju na desetke vodiča za početak, a GitHub nudi niz vlastitih vodiča, još uvijek nije lako pronaći zbirku korisnih savjeta za programere koji žele pametnije raditi s Gitom i GitHubom. Popravimo to.

Za one koji nisu upoznati s Gitom ili GitHubom, sljedećih nekoliko odlomaka dat će vam dovoljno pozadine za razumijevanje savjeta. Na kraju ovog članka navest ćemo desetak korisnih izvora.

Git je distribuirani sustav kontrole verzija, koji je izvorno napisao Linus Torvalds 2005. godine i uz pomoć zajednice Linux jezgre. Nisam ovdje da bih vas prodavao na Gitu, pa ću vas poštedjeti rasprave o tome koliko je brz, malen, fleksibilan i popularan, ali trebali biste znati da kad klonirate Git spremište ("repo", kratko) , na vlastitom računalu dobivate cijelu povijest verzija, a ne samo snimku iz jedne grane odjednom.

Git je započeo kao alat naredbenog retka, što odgovara njegovom podrijetlu u zajednici Linux kernela. I dalje možete koristiti naredbeni redak Git, ako želite, ali ne morate. Konkretno, ako GitHub koristite kao domaćina, možete koristiti besplatni klijent GitHub Desktop na Windowsima ili Macu. S druge strane, naredbeni redak Git radit će za bilo kojeg domaćina i dolazi predinstaliran na većinu Mac i Linux sustava.

Samo vi možete odlučiti hoće li vam biti ugodnije koristiti naredbeni redak ili izvorni klijent s grafičkim korisničkim sučeljem. Ako vam se sviđa GUI, uz GitHub klijent (Windows i Mac), možda biste trebali razmotriti SourceTree (Windows i Mac, besplatno), TortoiseGit (samo Windows, besplatno) i Gitbox (samo Mac, 14,99 USD). Ili možete koristiti uređivač ili IDE koji interno podržava Git (vidi savjet br. 11).

Git / GitHub savjet br. 1: Klonirajte gotovo sve

Iz GitHub-a i drugih javnih Git-ovih spremišta dostupni su mnogi zanimljivi projekti koje možete slobodno klonirati na svoje računalo. Zašto biste to željeli učiniti? Jedan od razloga je naučiti nešto o stilu kodiranja, praksi i alatima na jeziku od interesa, uključujući stil komentiranja dnevnika predavanja (vidi savjet br. 4). Drugi razlog je naučiti kako određeni projekt ostvaruje svoje ciljeve. Treći razlog, ako vam licenciranje to dopušta i ako ima smisla za vaše svrhe, bio bi uključivanje projekta u vaš vlastiti pothvat ili proizvod. Usput provjerite licencu kako kasnije ne biste nailazili na probleme s usklađenošću.

Definicija git clonesa stranice priručnika:

Klonira spremište u novostvoreni direktorij, stvara grane za daljinsko praćenje za svaku granu u kloniranom spremištu (vidljivo pomoću git branch -r) i kreira i provjerava početnu granu koja je račvasta iz trenutno aktivne grane kloniranog spremišta.

Nakon klona, ​​običan git fetchbez argumenata ažurirat će sve grane daljinskog praćenja, a git pullbez argumenata će uz to spojiti udaljenu matičnu granu u trenutnu glavnu granu, ako ih ima.

Git / GitHub savjet br. 2: Povlačite često

Jedan od najjednostavnijih načina da napravite nered za sebe s Gitom (i zapravo sa bilo kojim sustavom za kontrolu verzija) jest dopuštanje datotekama da se sinkroniziraju. Ako git pullčesto budete, redovito ćete ažurirati svoju kopiju i imat ćete priliku spojiti svoj promijenjeni kôd s promjenama drugih, dok je spajanje lako razumjeti i izvršiti - u idealnom slučaju, kada je tako lako da može biti učinjeno automatski. Posljedica ovog savjeta je promatranje statusa vašeg projekta. Mnogi Git klijenti automatski će vam pokazati kada trebate ažurirati kako biste ostali u toku.

Git / GitHub savjet br. 3: Počnite rano i često

Povlačenje je detaljno ažuriranje projekta, koje uključuje jednu ili više promjena u jednoj ili više datoteka. Shvatite to kao zapis o završenoj jedinici rada, koja se može primijeniti na projekt ili ukloniti iz njega kao logična cjelina. Obavljajte svaku logičku promjenu koju dovršite, čak i prije nego što je testirate. Obaveze se odnose samo na vaše lokalno spremište. Pogledajte savjete br. 4 i 5 za posljedice ovog savjeta.

Definicija git commitsa stranice priručnika:

Pohranjuje trenutni sadržaj indeksa u novom urezivanju zajedno s korisničkom porukom dnevnika koja opisuje promjene.

Savjet za Git / GitHub br. 4: Komentirajte svoje obveze kao što biste htjeli da i drugi komentiraju njihove

Postoji 10 vrsta kodera: oni koji komentiraju svoje obveze i oni koji to ne čine. (Stara šala. Savjet: Koju bazu koristim?)

Slobodno priznajem da sam sticker za dobre poruke dnevnika urezivanja. Postavio sam svoja spremišta da zahtijevaju poruke za svako urezivanje, a poznato mi je da šaljem iznervirane kasnonoćne poruke kada se predaje zemljište s zapisnicima po redoslijedu "xx". Ako ste vrsta programera koji misli da (1) kôd treba govoriti sam za sebe i (2) da su redoviti komentari puno važniji od dnevnika promjena, pokušajte klonirati spremište koje nikada prije niste vidjeli i identificirati nedavni predaj koji je mogao prouzročiti objavljivanje najnovijeg problema bez čitanja cijelog koda. Kao što vidite, precizni zapisnici urezivanja dvostruko su plus.

Git / GitHub savjet br. 5: Pritisnite kada se provjere vaše promjene

Najgora greška vezana uz Git koju sam ikada imao nesreću znati dogodila se kada se tvrtka koja je prenijela usluge outsourcinga preusmjerila sa Subverzije, ali nije obučila svoje programere o razlici između distribuirane kontrole izvora i centralizirane kontrole izvora. Otprilike mjesec dana kasnije, projekt je razvio čudne greške kojih se čini da nitko nije mogao ući u trag. Na svakodnevnim stand-up sastancima programeri odgovorni za područje aplikacije koja se loše ponašala protestirali bi: "To sam popravio prije dva tjedna!" ili optužite drugog programera da se ne trudi povući promjene koje su tako pažljivo provjerili.

Na kraju je netko prepoznao problem i naučio sve programere kako i kada se pushobvezuju: Ukratko, kad god se prijefizi uspješno testiraju u lokalnoj gradnji. Tada je tvrtka napravila dvodnevni fest spajanja prije nego što je uspjela izgraditi i implementirati ažurirani integrirani proizvod.

Git / GitHub savjet br. 6: Slobodno se granajte

Jedna od najvećih prednosti koje Git ima u odnosu na neke druge sustave za kontrolu inačica je ta što spajanje obično dobro funkcionira, barem djelomično jer Git automatski bira najboljeg zajedničkog pretka za spajanje. Većina programera softvera mora češće početi stvarati grane u svojim projektima. To bi trebala biti svakodnevna rutinska pojava, a ne tema mučnog sastanka o strategiji svih ruku. Vjerojatnost je da, kada je projekt podružnice dovršen, prihvaćen i spreman za prelazak u glavni projekt, spajanje neće predstavljati nepremostive probleme.

Znam da je za to potrebno neko prilagođavanje, pogotovo ako ste zapeli u tvrtki koja vrši kontrolu izvornog koda s CVS-om. Ali probajte. Puno je bolje od toga da kupci slučajno vide vaš nedovršeni eksperimentalni kôd kad se trunk projekt mora objaviti zbog kvara. (Ovaj članak dobro objašnjava osnovno grananje i spajanje.)

Git / GitHub savjet br. 7: Pažljivo spojite

Iako spajanja s Gitom obično dobro funkcioniraju, ako ih napravite bez razmišljanja, povremeno možete naići na poteškoće. Prvi korak je osigurati da nema neizmijenjenih promjena. Sa git mergestranice priručnika:

Prije primjene vanjskih promjena, trebali biste svoje vlastito djelo dovesti u dobru formu i predati mu se lokalno, tako da neće biti ometano ako postoje sukobi. Vidi također git-stash.

Također pogledajte savjet br. 8.

Čak i ako tijekom a sve krene na jug git merge, niste zaobiđeni:

Ako ste pokušali spojiti koje je rezultiralo složenim sukobima i želite početi ispočetka, možete se oporaviti pomoću git merge —abort.

Sljedeća naredba git mergeobično je git mergetool, pod pretpostavkom da volite koristiti GUI za spajanje. Ako biste radije način stare škole, možete urediti datoteke u sukobu sa svojom omiljenom programskom urednika, u potpunosti ukloniti <<<<<<<, =======i >>>>>>>linije, štedite izmijenjenim datotekama, a git addsvaka datoteka koju ste fiksna.

Git / GitHub savjet br. 8: Sakrijte prije zamjene grana

Tijek rada programera softvera rijetko je linearan. Korisnici imaju hrabrosti prijaviti bugove, upravitelji imaju drskosti da daju prednost kartama koje nisu one koje ste odabrali za rad, a vi sami biste se mogli predomisliti u vezi s onim što želite učiniti.

Tu ste, s tri datoteke predane za izdanje, i četvrta datoteka u promijenjenom, ali neradnom stanju. ( git statusNaredba će vam reći sve ovo ako se slučajno ne sjetite gdje ste bili.) Odjednom morate poraditi na ispravku programske pogreške u produkcijskoj verziji. Trebate prebaciti grane unaprijed, ali ne možete. Vaš je radni direktorij prljav i imate dva sata posla koji ne želite izgubiti.

Uđi git stash. Voilà! Sada imate sve promjene pohranjene u grani WIP-a (u tijeku), a iz čistog direktorija možete se prebaciti na produkcijsku granu. Kad završite s tim, vratite se tamo gdje ste bili git stash apply.

Savjet za Git / GitHub br. 9: Upotrijebite tabele za dijeljenje isječaka i pasta

GitHub-ovi "sadržaji" - dijeljeni isječci koda - nisu Git značajka, ali koriste Git. Svi su sadržaji Git spremišta, a GitHub Gist olakšava njihovo dijeljenje. U Gistu možete tražiti javne spiskove prema temi, programskom jeziku, račvastom statusu i statusu sa zvjezdicom. Također možete stvoriti tajne mastove i dijeliti ih putem URL-a.

Git / GitHub savjet br. 10: Istražite GitHub

Mnogi zanimljivi projekti otvorenog koda imaju spremišta na GitHubu. Istražite GitHub nudi sučelje za pregledavanje kako biste pronašli neke od njih, ali uglavnom je lakše unijeti nekoliko slova imena projekta u okvir za pretraživanje da biste pronašli njegove repoe. Na primjer, upišite jqili backili angda biste pronašli tri glavna JavaScript okvira otvorenog koda.

Git / GitHub savjet br. 11: Doprinite projektima otvorenog koda

Sve dok pregledavate projekte otvorenog koda, zašto im ne biste pridonijeli? Nije tako teško kao što možda mislite, a naučit ćete puno. Na primjer, možete klonirati projekt jquery / jquery (jQuery Core) i pregledavati README.MD. Pri vrhu ćete vidjeti:

U duhu razvoja softvera otvorenog koda, jQuery uvijek potiče doprinos kodu zajednice. Da biste lakše započeli i prije nego što uskočite u pisanje koda, pročitajte ove važne smjernice za doprinos ...

Nakon toga slijede tri poveznice. Prvi od trojice počet će vam prilično brzo. Ne planira svaki projekt otvorenog koda plan tako jasno, ali svi se trude.

Shvatite razliku između toga što ste suradnik i obveznik. Suradnik je potpisao potrebne ugovore i dao doprinos projektu. Povjerenik je ovlašten stvarno predati ponuđeni doprinos u spremište projekata. Budući da će doći do kašnjenja dok izvršitelj testira vaš doprinos i nećete htjeti vezati svoju glavnu granu, trebali biste unijeti promjene u drugu granu (pogledajte savjet br. 6) prije slanja zahtjeva za povlačenjem (vidi savjet br 16).