Vaikka Gitin käyttäjillä on kymmeniä aloitusoppaita, joista valita, ja GitHub tarjoaa useita omia oppaita, ei ole silti helppoa löytää hyödyllisiä vinkkejä kehittäjille, jotka haluavat työskennellä älykkäämmin Gitin ja GitHubin kanssa. Korjataan se.
Niille teistä, jotka eivät tunne Gitä tai GitHubia, muutama seuraava kappale antaa sinulle tarpeeksi taustaa vinkkien ymmärtämiseen. Tämän artikkelin lopussa luetellaan noin tusina hyödyllisiä resursseja.
Git on hajautettu versionhallintajärjestelmä, jonka Linus Torvalds kirjoitti alun perin vuonna 2005 Linux-ytimen yhteisölle ja sen avustuksella. En ole täällä myydäksesi sinua Gitissä, joten säästän sinulle spielin siitä, kuinka nopea, pieni ja joustava ja suosittu se on, mutta sinun pitäisi tietää, että kun kloonaat Git-arkiston (lyhyesti "repo") , saat koko versiohistorian omalle tietokoneellesi, ei vain tilannekuvan yhdestä haarasta kerrallaan.
Git aloitti komentorivityökaluna, joka sopi sen alkuperään Linux-ytimen yhteisöön. Voit silti käyttää Git-komentoriviä, jos haluat, mutta sinun ei tarvitse. Erityisesti, jos käytät isäntänä GitHubia, voit käyttää ilmaista GitHub Desktop -asiakasohjelmaa Windowsissa tai Macissa. Toisaalta Git-komentorivi toimii mille tahansa isännälle, ja se on esiasennettu useimpiin Mac- ja Linux-järjestelmiin.
Vain sinä voit päättää, oletko mukavin käyttää komentoriviä vai natiivia asiakasta, jolla on graafinen käyttöliittymä. Jos pidät graafisesta käyttöliittymästä, kannattaa harkita GitHub-asiakkaan (Windows ja Mac) lisäksi SourceTree (ilmainen Windows ja Mac), TortoiseGit (vain Windows, ilmainen) ja Gitbox (vain Mac, 14,99 dollaria). Tai voit käyttää editoria tai IDE: tä, joka tukee Gitiä sisäisesti (katso vinkki nro 11).
Git / GitHub-vinkki nro 1: Kloonaa melkein kaikki
GitHubista ja muista julkisista Git-arkistoista on saatavana monia mielenkiintoisia projekteja, jotka voit kloonata vapaasti omalle tietokoneellesi. Miksi haluat tehdä sen? Yksi syy on oppia jotain koodaustyylistä, käytännöstä ja työkaluista kiinnostavalla kielellä, mukaan lukien sitouttamislokin kommentointityyli (katso vinkki 4). Toinen syy on oppia, kuinka tietty projekti saavuttaa tavoitteensa. Kolmas syy, jos lisensointi sallii sinun tehdä niin ja on järkevää tarkoituksellesi, olisi sisällyttää projekti omaan pyrkimykseesi tai tuotteeseesi. Tarkista muuten lisenssi, jotta et myöhemmin törmää vaatimustenmukaisuusongelmiin.
Määritelmä git-klooni manuaalisivulta:
Kloonaa arkiston uuteen hakemistoon, luo etäseurannan haarat jokaiselle kloonatun arkiston haaralle (näkyvissä git-haara -r), luo ja tarkistaa alkuperäisen haaran, joka on haaroitettu kloonatun arkiston tällä hetkellä aktiivisesta haarasta.
Kloonin jälkeen tavallinen git noutaa ilman argumentteja päivittää kaikki etäseurannan haarat ja a git vetää ilman argumentteja yhdistää lisäksi etäpäällikköhaaran nykyiseen päähaaraan, jos sellaista on.
Git / GitHub-kärki nro 2: Vedä usein
Yksi helpoimmista tavoista tehdä sotku itsellesi Gitin (ja todellakin minkä tahansa versionhallintajärjestelmän) kanssa on antaa tiedostojen päästä pois synkronoinnista. Jos sinä git vetää usein pidät repo-kopiosi ajan tasalla ja sinulla on mahdollisuus yhdistää muutettu koodisi muiden muutoksiin, kun taas yhdistäminen on helppo ymmärtää ja toteuttaa - ihanteellisessa tilanteessa, kun se on niin helppoa, että se voidaan tehdä automaattisesti. Tämän vinkin seurauksena on seurata projektisi tilaa. Monet Git-asiakkaat näyttävät sinulle automaattisesti, kun sinun on päivitettävä pysyäksesi ajan tasalla.
Git / GitHub-vinkki 3: Sitoudu aikaisin ja usein
Sitoutuminen on rakeinen päivitys projektiin, joka sisältää yhden tai useamman muutoksen yhteen tai useampaan tiedostoon. Ajattele sitä tietueena valmistuneesta työyksiköstä, jota voidaan soveltaa projektiin tai poistaa siitä loogisena kokonaisuutena. Tee kaikki tekemäsi loogiset muutokset jo ennen niiden testaamista. Sitoumukset koskevat vain paikallista arkistoa. Katso vinkit nro 4 ja 5 tämän kärjen seurauksista.
Määritelmä git sitoutua manuaalisivulta:
Tallentaa hakemiston nykyisen sisällön uuteen sitoutumiseen sekä käyttäjän lokiviestin, joka kuvaa muutokset.
Git / GitHub-vinkki nro 4: Kommentoi sitoumuksiasi samalla tavalla kuin muutkin kommentoivat omiaan
Koodaajia on 10 erilaista: Ne, jotka kommentoivat tekojaan, ja ne, jotka eivät. (Vanha vitsi. Vihje: Mitä pohjaa käytän?)
Myönnän olevani tarra hyville sitoutumislokiviesteille. Perustin tietovarastoni vaatimaan viestejä jokaisesta sitoutumisesta, ja minun on tiedetty lähettävän ärtyneitä myöhäisillan viestejä, kun se sitoutuu laskeutumaan lokien kanssa järjestyksessä "xx". Jos olet sellainen kehittäjä, jonka mielestä (1) koodin pitäisi puhua puolestaan ja (2) rivikommentit ovat paljon tärkeämpiä kuin muutoslokit, yritä kloonata arkisto, jota et ole koskaan ennen nähnyt, ja tunnistaa äskettäinen sitoutuminen, joka on saattanut aiheuttaa viimeisimmän numeron, joka on lähetetty lukematta kaikkia koodeja. Kuten näette, tarkat sitoutumislokit ovat kaksinkertaiset ja hyvät.
Git / GitHub-vinkki nro 5: Paina, kun muutokset testataan
Pahin Gitiin liittyvä vika, josta olen koskaan ollut tietoinen onneton, tapahtui, kun ulkoistava yritys vaihtoi Subversionista, mutta ei kouluttanut kehittäjiä hajautetun lähteen ja keskitetyn lähdeohjauksen eroista. Noin kuukautta myöhemmin projekti kehitti outoja vikoja, joita kukaan ei näyttänyt löytävän. Päivittäisissä stand-up-kokouksissa väärin käyttäytyvän sovelluksen alueesta vastaavat kehittäjät protestoivat: "Korjasin sen kaksi viikkoa sitten!" tai syyttää toista kehittäjää siitä, ettei hän vaivaudu hankkimaan muutoksia, jotka he olivat niin tarkasti tarkistaneet.
Lopulta joku tunnisti ongelman ja opetti kaikille kehittäjille miten ja milloin työntää heidän sitoutumisensa: Lyhyesti sanottuna aina kun sitoutuminen testaa onnistuneesti paikallisessa koontiversiossa. Sitten yritys teki kahden päivän pituisen yhdistämisjuhlan ennen kuin pystyi rakentamaan ja ottamaan käyttöön päivitetyn, integroidun tuotteen.
Git / GitHub-kärki nro 6: Haara vapaasti
Yksi suurimmista eduista, joita Gitillä on joihinkin muihin versionhallintajärjestelmiin verrattuna, on se, että sulautuminen toimii yleensä hyvin, ainakin osittain siksi, että Git valitsee automaattisesti parhaan yhteisen esi-isän, jota yhdistämiseen käytetään. Useimpien ohjelmistokehittäjien on aloitettava haarojen luominen projekteihinsa useammin. Sen pitäisi olla rutiininomainen päivittäinen tapahtuma, ei aiheena ahdistuneelle käsien strategiakokoukselle. Todennäköisyys on, että kun haarakonttori on valmis, hyväksytty ja valmis siirtymään pääprojektiin, sulautuminen ei aiheuta ylitsepääsemättömiä ongelmia.
Tiedän, että siihen on tehtävä joitakin muutoksia, varsinkin jos olet juuttunut yritykseen, joka hallinnoi lähdekoodin hallintaa CVS: n avulla. Mutta kokeile sitä. Se on paljon parempi kuin se, että asiakkaat näkevät vahingossa keskeneräisen kokeellisen koodisi, kun runkoprojekti on julkaistava rikkovan virheen takia. (Tässä artikkelissa selitetään hyvin haarautumisen ja yhdistämisen perusteet.)
Git / GitHub-kärki nro 7: Yhdistä varovasti
Vaikka sulautuminen Gitin kanssa toimii yleensä hyvin, jos teet ne ajattelematta, voit toisinaan kohdata vaikeuksia. Vaihe yksi on varmistaa, että sinulla ei ole sitomattomia muutoksia. Alkaen git sulautua manuaalinen sivu:
Ennen ulkopuolisten muutosten tekemistä sinun on saatava oma työsi hyvässä kunnossa ja sitoutunut paikallisesti, joten sitä ei ryöstetä, jos on ristiriitoja. Katso myös git-stash.
Katso myös vinkki nro 8.
Vaikka kaikki menisi etelään a git sulautua, sinua ei letkuteta:
Jos yritit yhdistämistä, joka johti monimutkaisiin konflikteihin, ja haluat aloittaa alusta, voit toipua git sulautua - abortti.
Jatkokomento git sulautua on yleensä git mergetool, olettaen, että haluat yhdistää GUI: n. Jos haluat mieluummin vanhan koulun menetelmän, voit muokata tiedostoja, jotka ovat ristiriidassa suosikki ohjelmointieditorin kanssa, poista tiedosto kokonaan <<<<<<<, =======ja >>>>>>> rivit, tallenna tarkistetut tiedostot ja git lisää jokainen korjaamasi tiedosto.
Git / GitHub-kärki nro 8: Pujota ennen oksan vaihtamista
Ohjelmistokehittäjän työnkulku on harvoin lineaarista. Käyttäjillä on mahdollisuus ilmoittaa virheistä, johtajilla on rohkeutta priorisoida muut liput kuin se, jonka valitsit työskennellä, ja sinä itse saatat muuttaa mieltäsi siitä, mitä haluat tehdä.
Tässä on kolme tiedostoa, jotka on sidottu julkaisua varten, ja neljäs tiedosto muutetussa, mutta ei-toimivassa tilassa. ( git-tila komento kertoo kaiken tämän, jos et satunnaisesti muista missä olit.) Yhtäkkiä sinun on työskenneltävä virhekorjauksen kanssa tuotantoversiossa. Sinun täytyy vaihtaa haaroja pronto, mutta et voi. Työhakemisto on likainen ja sinulla on kaksi tuntia työtä, jota et halua menettää.
Tulla sisään git stash. Voilà! Nyt kaikki muutoksesi on tallennettu WIP (work in progress) -haaraan ja voit siirtyä tuotantohaaraan puhtaasta hakemistosta. Kun olet valmis, vaihda takaisin sinne, missä olit Git stash sovelletaan.
Git / GitHub-vinkki nro 9: Jaa katkelmia ja tahnoja luetteloiden avulla
GitHubin "gists" - jaetut koodinpätkät - eivät ole Git-ominaisuus, mutta ne käyttävät Gitiä. Kaikki olennot ovat Git-arkistoja, ja GitHub Gist tekee niiden jakamisesta helppoa. Voit hakea Gististä julkisia luetteloita aiheen, ohjelmointikielen, haarautuneen tilan ja tähdellä merkityn tilan mukaan. Voit myös luoda salaisia luetteloita ja jakaa ne URL-osoitteella.
Git / GitHub-vinkki nro 10: Tutustu GitHubiin
Monilla mielenkiintoisilla avoimen lähdekoodin projekteilla on GitHub-arkistoja. Explore GitHub tarjoaa selauskäyttöliittymän joidenkin löytämiseen, mutta useimmiten on helpompaa kirjoittaa muutama kirjain projektin nimestä hakukenttään löytääksesi repot. Kirjoita esimerkiksi jq tai takaisin tai ang löytää kolme tärkeintä avoimen lähdekoodin JavaScript-kehystä.
Git / GitHub-vinkki nro 11: Osallistu avoimen lähdekoodin projekteihin
Niin kauan kuin selaat avoimen lähdekoodin projekteja, miksi et edistäisi niitä? Se ei ole niin vaikeaa kuin luulisi, ja opit paljon. Voit esimerkiksi kloonata jquery / jquery (jQuery Core) -projektin ja selata README.MD-tiedostoa. Yläosan lähellä näet:
Avoimen lähdekoodin ohjelmistokehityksen hengessä jQuery rohkaisee aina yhteisökoodeja. Lue nämä tärkeät ohjeet huolellisesti, jotta pääset alkuun ja ennen kuin kirjoitat koodia.
Tätä seuraa kolme linkkiä. Ensimmäinen kolmesta pääset alkuun melko nopeasti. Kaikki avoimen lähdekoodin projektit eivät esitä suunnitelmaa niin selkeästi, mutta he kaikki yrittävät.
Ymmärrä ero osallistujana ja sitouttajana olemisen välillä. Avustaja on allekirjoittanut vaaditut sopimukset ja antanut panoksen projektiin. Sitoutajalla on valtuudet todella sitouttaa tarjottu panos projektivarastoon. Koska viivästys tapahtuu, kun sitoutuja testaa panoksesi, etkä halua sitoa päähaaraa, sinun tulee tehdä muutokset toisessa haarassa (katso vihje nro 6) ennen vetopyynnön lähettämistä (katso vinkki nro 16).
