Jos kirjoitat ohjelmistoa elantonasi varten vuonna 2018, voin sanoa luottavaisin mielin, että tunnet Gitin. Linus Torvaldsin luomasta työkalusta on tullut synonyymi versionhallinnalle. Ja epäilemättä yksi Gitin parhaista ominaisuuksista on se, kuinka se poistaa haarautumisen ja sulautumisen. Voit luoda haaran Gitiin useilla tavoilla. Tässä viestissä ”tarkastelemme joitain niistä. Sitten lopetamme pienellä pohdinnalla Gitin haarautumismallista ja haarautumisesta yleensä.

Haaran luominen päälliköltä

Luot oksat Gitissä yllättäen käyttämällä haarakomentoa. Kuten monet muutkin Git-komennot, ”haara” on erittäin tehokas ja joustava. Haarojen luomisen lisäksi sitä voidaan käyttää myös niiden luettelointiin ja poistamiseen. komento käyttämällä laajaa luetteloa parametreista. Aloitamme ensimmäisellä tavalla luoda haara. Sanotaan, että haluat luoda uuden kansion nimeltä ”my-app”, kirjoita se ja aloita uusi Git-arkisto. Näin teet sen:

mkdir my-appcd my-appgit init

Nyt sinulla on uusi, tyhjä Git-arkisto. Mutta tyhjät arkistot ovat tylsiä. Entä uuden markdown-tiedoston luominen, johon on kirjoitettu ”Hello World!”?

echo Hello World! > file.md

Jos suoritat ”git status”, sinun pitäisi nähdä viesti, jonka mukaan tiedostosi on jäljittämätön:

Lataamattomat tiedostot ovat kuitenkin myös jäähtymättömiä, joten seuraakaamme sitä:

git add file.md

Ja lopuksi anna meidän luoda ensimmäinen sitoutuminen:

git commit -m "First commit"

Meillä on nyt yksi haarainen arkisto, jolla on täsmälleen yksi sitoutuminen. Se ei ehkä kuulosta mielenkiintoisin asia maailmassa (koska se ei todellakaan ole ”t”), mutta se ei todellakaan ole yhtä tylsää kuin repo, jolla ei ole mitään tekemistä, eikö? Sanotaan nyt, että jostain syystä sinun on vaihdettava tiedosto sisältöä. Mutta et tuntuu tekevän niin. Entä jos jokin menee pieleen ja pilaat jotenkin tiedostosi kauniin, koskemattoman sisällön? (Joo, tiedän, että se on vain joku tyhmä tiedosto, jossa on ”Hello World!”, Mutta käytä mielikuvituksesi upeita voimia ja ajattele tiedostoa paljon monimutkaisemman projektin välityspalvelimena.) Ratkaisu tähän ongelmaan luo tietysti uuden haaran:

git branch exp

Joten nyt meillä on uusi haara nimeltä ”exp” kokeilua varten Jotkut ihmiset, jotka ovat tottuneet käyttämään erilaisia versiojärjestelmiä, etenkin keskitettyjä, voivat sanoa, että haaroilla on sama ”sisältö”. Tämä ei kuitenkaan ole täysin tarkka puhuessaan Gitistä. Ajattele sivuliikkeitä, kuten viittauksia, jotka viittaavat annettuun sitoutumiseen.

Haaran luominen toimeksiannosta

Oletetaan, että jostain syystä luopumme kokeestamme lisäämättä yhtään sitoutua uuteen haaraan. Palataan ”s” takaisin masteriin ja poistetaan exp-haara:

git checkout mastergit branch -d exp

Nyt kun palataan takaisin yhteen haaraan, lisätään siihen joitain sitoumuksia simuloimaan tehtyä työtä:

Kuvittele, että kun olet tehnyt kaiken tämän ”työn”, opit, että jostain syystä sinun on palattava ajassa taaksepäin olivat vain kaksi riviä tiedostossa ja luovat uusia muutoksia siitä lähtien. Mutta samalla sinun on säilytettävä jo tekemäsi edistys. Toisin sanoen haluat luoda haaran aikaisemmasta sitoutumisesta. Kuinka tekisit sen ? Gitissä jokaisella sitoutumisella on yksilöllinen tunniste. Joten voit helposti nähdä tämän käyttämällä ”git log” -komentoa. Jos haluat luoda uuden haaran tiettyyn sitoutumiseen, välitä vain sen hash parametrina haarakomentoon:

git branch new-branch 7e4decb

Sivuseinona et tarvitse edes koko hashia suurimman osan ajasta. Vain viisi tai kuusi merkkiä tekevät sen.

Haaran luominen tunnisteesta

Jos olet hieman kokeneempi Gitin kanssa, sinun tulisi tuntea tagien käsite. Tunnisteiden avulla osoitat, että tietty sitoutuminen on jollain tavalla tärkeä tai erityinen. Esimerkiksi tunnisteita käytetään yleensä tuotteen todellisten versioiden osoittamiseen. Jos olet työskennellyt sovelluksessasi jonkin aikaa ja uskot, että on aika julkaista versio 1.0, mitä yleensä teet, on kolahtaa versionumerot aina kun se on tarpeen, tekemällä nämä muutokset ja lisäämällä sitten tunniste kyseiseen ajankohtaan. Tunnisteen luominen edellyttää yleensä jotain tällaista:

git tag -a v1.0 -m "First major version"

Parametri ”-a” osoittaa, että tämä on menossa Toisin kuin kevyt tunniste, tämä on täysimittainen Git-objekti, joka sisältää tietoja, kuten lähettäjän nimi ja sähköpostiosoite, aikaleima ja viesti. Nyt sinulla on tunniste, osoitus siitä, että tämä historian kohta on erityinen ja sillä on nimi. Kiva. Voit jatkaa työn tekemistä tavalliseen tapaan, luoda ja tehdä muutoksia, jotka ovat osa 1.1-versiota. Kunnes vikailmoitus tulee. Jotkut asiakkaista, jotka päivitettiin 1.Tuotteen 0 version mukaan tuontiominaisuus ei toimi tarkoitetulla tavalla. Voit teoriassa korjata virheen päähaarassa ja ottaa sen käyttöön. Mutta sitten asiakkaat saisivat ominaisuuksia, jotka ovat mahdollisesti testaamattomia ja epätäydellisiä. -ei. Joten mitä sinä teet? Vastaus: Loit uuden haaran luomastasi tunnisteesta osoittamaan pääversiota. Korjaat ongelman siellä, koot ja asennat. Ja sinun pitäisi todennäköisesti yhdistää tämä takaisin masteriksi myöhemmin, joten seuraavat julkaisut sisältävät korjauksen Kuinka menisit siihen? Helppo:

git branch <NAME-OF-THE-BRANCH> <TAG>

Tarkemmin sanottuna edellisen esimerkkimme avulla:

git branch fix-bug-123 v1.0

Tämän jälkeen voit tarkistaa uuden haarasi tavalliseen tapaan. Tai vielä parempaa, voit tehdä sen kaikki yhdessä vaiheessa:

git checkout -b fix-bug-1234 v1.0

Sivuliikkeen luominen irrotettuun päävaltioon

Oletko koskaan halunnut palata ajassa taaksepäin? mahdollista … ainakin arkistossa olevien tiedostojen osalta. Voit milloin tahansa tarkistaa sitoutumisen, jos tiedät sen hash:

git checkout <SHA1>

Sen suorittamisen jälkeen Git näyttää sinulle utelevan viestin:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Kun kirjaudut ulos sitoutuminen, annat erityistilan c Alled, kuten näette, ”irrotettu PÄÄ”. Vaikka voit tehdä muutoksia tässä tilassa, nämä sitoumukset eivät kuulu mihinkään haaraan, ja niistä ei pääse heti, kun tarkistat toisen haaran. Mutta entä jos haluat säilyttää nämä sitoumukset? Vastaus on yllättämätön käyttää ”checkout” -komento uudelleen uuden haaran luomiseksi:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

Ja tietysti, nyt tiedät, että voit kirjoittaa kaksi viimeistä riviä yhtenä komentona:

git checkout -b new-branch-to-keep-commits

Melko helppoa, eikö?

Vain siksi, että voit … Ei tarkoita, että sinun pitäisi

Gitin haarautumismalli on yksi sen myyntikohteista. Se muuttaa sen, mikä muissa lähdeohjausjärjestelmissä on tuskallinen ja jopa hidas prosessi. Voisi sanoa että Git on onnistuneesti demokratisoinut haarautumisen massoille, mutta siihen liittyy vakava vaara. Gitin haarautumisen halpuuden vuoksi jotkut kehittäjät saattavat joutua ansaan työskennellessään erittäin pitkäikäisten haarojen kanssa tai käyttämällä työnkulkuja tai haarautumismalleja, jotka viivästyttävät in armeija. Me teollisuutena olemme olleet siellä. Olemme tehneet sen. Se ei toimi. Ota sen sijaan käyttöön työnkulut, joissa käytetään erittäin lyhytaikaisia haaroja. Sinulla on turvallinen hiekkalaatikko, johon koodata pelkäämättä rikkoa tavaraa tai tuhlaa työtovereidesi aikaa. Mutta kysytkö sinä: ”Kuinka otan käyttöön koodin, jossa on osittain valmiit ominaisuudet?” Siinä tapauksessa se sisältää lippuja pelastukseen. Git-oksat ovat tehokas työkalu. Käytä niitä viisaasti ja älä väärinkäytä niitä. Ja kun niitä ei riitä, käytä jatkuvaa toimitusta / jatkuvaa integrointia yhdessä ominaisuuslippujen kanssa – mukaan lukien käytettävissäsi olevat erikoistyökalut -, jotta sovelluksesi voivat siirtyä seuraavalle tasolle.