Git

Wikipediasta
Siirry navigaatioon Siirry hakuun
Tulostettavaa versiota ei enää tueta ja siinä voi olla renderöintivirheitä. Päivitä selaimesi kirjanmerkit ja käytä selaimen tavallista tulostustoimintoa sen sijaan.
Git
Luoja Linus Torvalds
Kehittäjä Linus Torvalds, Junio Hamano sekä lukuisia muita
Kehityshistoria
Ensijulkaisu 7. huhtikuuta 2005
Vakaa versio 2.47.0 ()[1]
Kehitystilanne Aktiivinen
Tiedot
Ohjelmistotyyppi Versionhallinta
Alusta Linux, macOS, POSIX, Solaris, Windows
Ohjelmointikielet C, Bourne Shell, Perl, TCL[2]
Lisenssi GPLv2,[3] LGPL
Aiheesta muualla
git-scm.com
Versiohallinta

Git on hajautettu versionhallintajärjestelmä, joka on suunniteltu toimimaan tehokkaasti ja luotettavasti.[4][5]

Git on suunniteltu POSIX-yhteensopiville käyttöjärjestelmille (mukaan lukien Linux ja macOS). Se toimii myös Microsoft Windowsilla; virallinen asennuspaketti perustuu MinGW MSYSiin ja sisältää myös tyypillisiä POSIX-ympäristöjen apuohjelmia, kuten Bash-komentotulkin ja OpenSSH-asiakasohjelman. Git voidaan asentaa Windowsiin myös Cygwin-järjestelmän osana. Unix-suunnittelufilosofian mukaisesti Git ei ole yksittäinen sovellusohjelma, vaan koostuu suuresta joukosta pienempiä sovelluksia, joista kukin toteuttaa yksittäisiä toimintoja.

Gitin sanotaan olevan kolmannen sukupolven versionhallintajärjestelmä, joka toimii hajautetusti ja seuraa muutosjoukkoja.[6] Muita vastaavia versionhallintajärjestelmiä ovat Mercurial ja GNU Bazaar.[6]

Gitin alkuperäinen kehittäjä Linus Torvalds kertoo hajautetun järjestelmän eduksi, että politikointi käyttäjäoikeuksista poistuu: jokaisella käyttäjällä on oma tietovarasto (engl. repository).[7] Hajautettu versionhallinta mahdollistaa myös helpot ja luotettavat varmuuskopiot ja henkilökohtaisten kokeellisten tietovarastojen käytön.[7] Aiemmissa järjestelmissä muutoksien yhdistäminen (engl. merge) oli monimutkainen operaatio.[7]

Historia

Linux-ytimen versionhallintaan käytettiin vuonna 2002 käyttöön otettua BitMoverin suljetun lähdekoodin BitKeeper-ohjelmistoa.[8] BitMover antoi BitKeeperin ilmaiseen käyttöön avoimen lähdekoodin projekteille, mutta sen ehtoja ja ratkaisua kritisoitiin.[8][7] BitKeeper käytti hajautettua mallia, joka inspiroi projekteja kuten GNU Arch, Darcs ja Monotone.[8]

Vuonna 2005 Andrew Tridgell pyrki tekemään BitKeeperiä käyttävän ohjelman takaisinmallinnuksella, joka oli vastoin BitKeeperin käyttöehtoja.[7] Torvalds yritti sovitella Tridgellin ja BitMoverin Larry McVoyn välillä, mutta päättivät lopettaa BitKeeperin käytön.[7][9] Katsottuaan vaihtoehtoja Torvalds päätti kirjoittaa oman hajautetun versionhallintajärjestelmän korvaajaksi, koska Linux-ytimen kehitystiimin tarpeet täyttävää avoimen lähdekoodin järjestelmää ei tuolloin ollut olemassa.[7][10] Kehityshetkellä olemassa olleissa muissa järjestelmissä oli omat ongelmansa kuten tiedostojen uudelleennimeämisen seuranta ja suorituskyky.[7]

Torvalds inhosi keskitettyä mallia kuten Subversionissa ja kehotti katsomaan vaihtoehtoja kuten Monotonea.[11][12] Torvalds kritisoi Monotonea eräistä seikoista kuten tavasta käyttää ”tietokanta per kehittäjä” -mallia eikä ”tietokanta per lähdekoodipuu” -mallia.[13][14] Myös Monotonen suorituskyky oli yksi vaikuttava tekijä: suorituskyky oli yksi keskeisistä vaatimuksista ja Monotone oli huomattavan hidas Linux-ytimen tiedostomäärällä.[13][8][15]

Torvalds kertoo aloittaneensa Gitin kehityksen 3. huhtikuuta 2005 viimeisen BitKeeperillä tehdyn ytimen version 2.6.12-rc2 julkaisun jälkeen.[16] Itseään tukeva (engl. self-hosting) Gitistä tuli noin päivässä: suuri osa kehitystyöstä ei ollut ohjelmakoodin kirjoittamista vaan tietojen käsittelyn suunnittelua.[7] Itseään tukevana pidetään kuitenkin 7. huhtikuuta tehtyä tallennusta.[17] Ensimmäinen muutoksien yhdistäminen Linux-ytimeen Gitillä tapahtui 17. huhtikuuta 2005.[18] Ensimmäinen Gitillä ylläpidetty Linux-ytimen julkaisu oli versio 2.6.12 kesäkuussa 2005.[19]

Torvalds on kertonut, että koska on käyttänyt BitKeeperiä pitkään toimintamalli vain seuraisi BitKeeperin mallia eikä sen teknisiä yksityiskohtia: Torvalds tietoisesti pyrki välttämään BitKeeperin kloonin tekemistä.[20][10]

Torvalds ilmoitti 27. heinäkuuta 2005 Gitin ylläpidon siirtymisestä Junio Hamanolle, joka oli innokas kehittäjä.[21][8]

Varhaiset Git-komennot olivat vaikeaselkoisia, jotka kehittyivät Hamanon kehittäessä työkaluja.[7][8]

Nimeäminen

”Git” tarkoittaa brittiläisessä slangissa hölmöä tai hyödytöntä henkilöä tai jääräpäistä henkilöä.[22][23] Linus Torvalds sanoi ”Olen itsekeskeinen paskiainen, joten nimeän kaikki projektit itseni mukaan. Ensin Linux, nyt git.” (”I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git.”).[24] Kehityksen alkuvaiheissa nimeä kuvailtiin seuraavasti:[25]

»Linus Torvalds nimesi ohjelmiston ”gitiksi” kun hän loi ensimmäisen version. Hänen mukaansa kyseessä on ”tyhmä sisällönseurantaohjelmisto”, jota voidaan kuvailla mieltymysten mukaan:

  • Satunnainen äännettävissä oleva kolmikirjaiminen nimi, jota olemassa oleva Unix-ohjelma ei käytä. Se, että se voidaan virheellisesti lausua kuten ”get”, on ehkä asiaan kuuluvaa.
  • Tyhmä. Halveksittava ja kamala. Yksinkertainen. Valitse suosikkisi slangisanakirjasta.
  • ”Globaali Informaatio-Trakkeri”: Kun olet hyvillä mielin ja se sattuu toimimaan. Enkelikuoro laulaa ja valo täyttää huoneen.
  • ”Goddamn Idiotic Truckload of sh*t”: Kun se ei toimi.»

Erityisominaisuudet

Git suunniteltiin olemaan mahdollisimman nopea (Linux-ytimeen tulee valtava määrä muutoksia), tukemaan hajautettua työskentelyä, ja estämään datan virheellisyys sekä katoaminen. Sen oli myös kyettävä hallitsemaan Linuxin valtavaa kokoluokkaa, toisin kuin monet muut järjestelmät, jotka eivät skaalaudu isojen hakemistopuiden hallintaan. Git suunniteltiin myös eri kehityshaarojen tehokkaaseen ja helppoon hyödyntämiseen.

Git on suunniteltu Unix-filosofian mukaiseksi ”työkalusarjaksi”: Gitissä on joukko ohjelmia, joista kukin tekee yhden tietyn asian hyvin.[26]

Useimmissa muissa versionhallintajärjestelmissä on seurattu Source Code Control Systemin (SCCS) ”ajatusmallia”: niissä eräät toiminnot ovat olleet rivikohtaisella toiminnolla ja ylemmän tason ”näkymä” on puuttunut.[27] Gitissä blame-toiminto on laajempi ja annotate taaksepäin yhteensopivuuden vuoksi muista järjestelmistä tulevia varten.[28][29]

Tiedostojen uudelleennimeäminen Gitissä on implisiittistä: sitä ei nimenomaisesti seurata vaan se tulee ”automaattisesti”.[27] Vanhemman CVS:n yleisenä heikkoutena pidetään sen tapaa tunnistaa koko päivityshistoria tiedoston nimen mukaan, jolloin tiedoston siirtäminen tai uudelleennimeäminen ei ole mahdollista joko keskeyttämättä tai uudelleennimeämättä sen historiaa, tehden siitä virheellistä. Useimmat uudemmat versionhallintajärjestelmät antavat tiedostoille oman pysyvän nimensä (tiedostojärjestelmissä käytetyn ”inoden” kaltaisen).[30] Git ei käytä tämänkaltaisia tunnisteita,[30][31] sillä koodia joudutaan välillä paloittelemaan tai yhdistelemään uudelleennimeämisen lisäksi.[32] Tämän ylöskirjaaminen pelkkänä uudelleennimeämisenä jäädyttäisi historian jälleen virheelliseksi, mistä johtuen Git tunnistaa uudelleennimeämiset automaattisesti tallennehistoriaa selaamalla sen sijaan, että se kirjattaisiin jo tallennushetkellä.[33] (Yksinkertaistettuna version N jokin tiedosto on uudempi kuin N-1:n. Kun N-1:stä ei löydy kyseisen nimistä tiedostoa, Git etsii tiedostoa joka löytyy vain tästä versiosta, ja on sisällöltään mahdollisimman samanlainen uudempaan verrattuna.) Tämä vaatii kuitenkin luonnollisesti enemmän säikeitä (kuormittaen siten prosessoria) sekä monenlaisia asetuksia kontrolloimaan heuristiikkaa.

Gitin on myös päätetty olevan seuraamatta tyhjiä hakemistoja. Tästä syystä pelkkien hakemistojen seuraamiseen on kansioon luotava aina vähintään yksi tyhjä tiedosto (esim. .gitignore).[34]

Gitissä lähes jokainen operaatio on paikallinen: tämä mahdollistaa työskentelyn myös ilman jatkuvaa verkkoyhteyttä.[35] Paikallisen lisäksi voi käyttää jaettua verkkolevyä (kuten NFS) tai palvelinta (HTTP, SSH ja Git-protokollat).[36][37] Tietovarastoon voi liittää muita tietovarastoja, joihin viitataan lyhyillä nimillä (kuten origin, joka on oletusnimi tietovarastolle, josta olet kloonannut).[38] Esimerkiksi eri kehittäjien tietovarastoista voi hakea muutoksia omaan tietovarastoon (sekä paikallisesti että verkon kautta).[38]

Git eroaa useimmista versionhallintajärjestelmistä seuraamalla tilannekuvia (engl. snapshot) yksittäisten tiedostojen erojen (delta) sijaan.[35][27]

Gitin tietovarasto tukee useita lähdekoodipuita (worktree).[39] Uusi lähdekoodipuu on ”linkitetty puu” eikä ”pääpuu” kuten init- tai clone-komennolla tehdessä.[39]

Kaikelle Gitissä säilötylle lasketaan tarkistussumma SHA-1 tiivistefunktiolla jolla muutokseen viitataan: tämän johdosta on mahdotonta muuttaa minkään tiedoston sisältöä ilman että versiohallinta tietää siitä, jolloin et voi kadottaa tietoa tai menettää tietoa korruptoitumiselle.[35] Torvaldsin mukaan ajatus sisällönosoittamistekniikasta on lainattu Monotonesta.[15][17] Gitin käyttämä sisällönosoittaminen ja tapa säilöä tietoa objekteissa (muutostiedostojen sijaan) mahdollistaa minkä vain sisällön tallentamisen Gitissä.[40]

Torvalds on kertonut kääntyneensä Bitkeeperin kehittäjän Larry McVoyn kannalle siinä, että ”kirsikan poimiminen” (engl. cherry picking, tiettyjen muutoksien valinta) on väärä toimintamalli, joka viittaa tiettyjen henkilöiden olevan ”ylhäällä” ja toisten ”alhaalla”: Linux-ytimen kehitys on entistä enemmän ”verkkomalli”, jossa Torvalds on vain ”keskeinen henkilö” eikä ”päällimmäinen”.[14] Git tukee eri toimintamalleja versiohallinnassa kuten keskitetty työmalli, integraationhoitajamalli ja hyväntahtoinen diktaattorimalli, joissa muutokset etenevät yhden tai useamman tietovaraston kautta.[41] Tiettyjen muutoksien valinta on mahdollista git cherry-pick -komennolla.[42]

Haarojen käyttö

Gitissä haarojen (branch) tekeminen ja niiden välillä vaihtaminen (switch, checkout) ovat nopeita ja se kannustaa toimintamalleihin, joissa haarautumista ja yhdistämistä (merge) tehdään paljon.[43][44][45] Monissa versionhallintatyökaluissa haarojen tekeminen ja yhdistäminen on vaativa toimenpide, joka voi vaatia uuden kopion lähdekoodeista, joka on hidasta suurissa projekteissa.[43]

Haaran vaihtamisen yhteydessä Git pyrkii varmistamaan ettei tietoja kadoteta ja huomauttaa, jos työkopiossa on tallentamattomia muutoksia: muutokset voi tallettaa (commit) tai vaihtoehtoisesti säilöä (stash) jos muutokset eivät ole valmiita talletettavaksi.[46][47] Haaran vaihdossa Git pyrkii palauttamaan viimeisimmän talletuksen tilan.[46] Säilö (stash) toimii pinon kaltaisella periaatteella, jossa muutoksia säilötään päälle ja niitä haetaan päältä: lisäksi voi viitata suoraan haluttuun muutokseen jonka haluaa palauttaa päällimmäisenä olevan sijaan.[47]

Muutoksien yhdistäminen tukee erilaisia menetelmiä: resolve, recursive ja octopus, joista viimeisessä voi olla useita lähteitä yhdistettävänä.[48] Uudempi menetelmä on ort, jossa käytetään samoja konsepteja, mutta suorituskyky on parempi.[49][50] Jos haaraan yhdistetään muutoksia, jotka ovat lähdekoodipuussa suoraan edellä voidaan suorittaa ”pikakelaus” (”fast-forward”) eli vain päivitetään viittaamaan uudempaan ilman varsinaista yhdistysoperaatiota.[46] Samaan kohtaan kohdistuvat muutokset voivat aiheuttaa konfliktin, jossa ohjelma ei automaattisesti pysty päättelemään mikä on oikea lopputulos.[48][46] Konfliktin ratkaisuksi voidaan muokataan työversiossa olevaa lähdekoodia, johon on merkitty eri versioiden muutokset.[46]

Alimoduulit ja alipuut

Git tukee alimoduulien (submodule) tallentamista osana laajempaa projektia: käyttökohde on erikseen seurattavat projektit jotka voivat riippua toisistaan.[51][52] Projekti voi riippua toisista projekteista, joita käytetään myös toisissa projekteissa.[53] Lähdekoodin kopiointi jokaiseen projektiin joka käyttää sitä on työlästä ja vaikeuttaa päivittämistä.[53] Alimoduulilla voi viitata suoraan toiseen projektiin ilman sen kopioimista.[53] Alimoduuli viittaa tiettyyn talletukseen tietovarastossa.[53]

Alipuu (subtree) tekee vastaavan kuin alimoduuli eli sallii toisen tietovaraston sijoittamisen toisen alle, mutta ei käytä erillistä seurantaa sen hakemistopuulle.[53][54] Yksinkertaistettuna alipuu on kopio toisesta tietovarastosta kun taas alimoduuli on vain viittaus toiseen tietovarastoon.[55]

Tiivisteet

Git käyttää nykyisin SHA-1-tiivistefunktiota tiedostojen seurantaan.[56] Git siirtyi versiossa 2.13.0 vahvennettuun SHA-1:een, joka ei ole haavoittuvainen vuonna 2017 julkaistulle SHAttered-hyökkäykselle.[57] Siirtyminen uudempaan SHA-2 standardiin on työn alla.[56][58]

Olioiden tallennus Gitissä on yksinkertaistettuna "vain" suunnattu syklitön verkko, jossa on kourallinen eri oliotyyppejä, joihin viitataan tiivisteellä.[59]

Git tallettaa tietoa useisiin objekteihin.[60] Tiedostoihin viitataan niiden sisällöstä lasketulla tiivisteellä.[60] Tiedoston siirtäminen eri hakemistoon tai sen nimen muuttaminen ei muuta sen tiivistettä, mutta hakemiston sisältöä luetteloivan hakemisto-objektin tiiviste muuttuu.[60] ”Commit”-objekti sisältää tietovaraston tilanteen tietyllä ajanhetkellä.[60] ”Commit”-objekti sisältää metatietoa kuten tekijän ja aikaleiman, tiivisteen hakemistopuusta sekä edellisen talletuksen tiivisteen (tai useamman talletuksen muutoksien yhdistämisen tapauksessa).[60] Näillä tiedoilla Git voi tuottaa tietovarastossa olevien tiedostojen tilan kullekin tallennukselle ja voi havaita mitä tietovarastossa on muuttunut.[60]

Muutos tiedoston sisältöön muuttaa sen omaa tiivistettä, tiedoston sisältävän hakemiston tiivistettä ja tietovaraston tilaan viittaavaa tiivistettä.[60]

Digitaalinen allekirjoitus

Git tukee digitaalista allekirjoittamista ja sen tarkistamista GPG:llä.[61][60] Kehittäjät voivat allekirjoittaa yksittäisen muutoksen (commit -S) tai koko tietovaraston tilan (engl. signed tag, tag -s) ja tiivisteiden käytöllä havaitaan mikäli tietovarasto ei ole sama kuin on allekirjoituksella vahvistettu.[61][60]

Käyttäjäoikeudet

Git ei itse käsittele käyttäjäoikeuksia, vaan siihen käytetään olemassa olevia työkaluja kuten SSH, tiedostojärjestelmän asetukset, käyttäjäoikeuslistat (ACL) ja muita tekniikoita.[62] Linux-ytimen versiohallinnassa käytetään gitolite-ohjelmaa oikeuksien hallintaan.[63]

Suorituskyky

Vertailussa GNU Bazaarin ja Mercurialin kanssa Git oli kertaluokkia nopeampi.[64]

Koska Git ei tarvitse verkkoyhteyttä muutoshistorian selaamiseen se on merkittävästi nopeampi kuin Subversion historian selaamisessa.[65]

Varmuuskopiot

Torvaldsin mukaan järjestelmän etuna on helpot ja luotettavat varmuuskopiot.[7] Gitiä on sanottu varmuuskopiointijärjestelmäksi itsessään ja käytetty muun muassa tietokannoille.[66][67]

Tietojen eheyden ja oikeellisuuden tarkistamiseen on git fsck -komento.[68] Lisäksi git tekee taustalla useita asioita ylläpidollisiin tarkoituksiin.[69]

Suuret tietovarastot

Suurien tietovarastojen kanssa toimintaan on lisätty osittainen kloonaaminen sekä "harva checkout" (git sparse-checkout): näillä ominaisuuksilla haetaan paikalliseksi vain osa tietovaraston objekteista ja työkopiosta käytetään vain osa, joka on tyypillsesti rajattu tiettyihin alihakemistoihin.[70][71] Tyypillisesti tietovarasto Gitissä sisältää kaiken tiedon ja koko historian: osittaisella kloonilla voidaan rajata käyttö tiettyyn alihakemistoon.[72]

Suurien referenssimäärien (haarat ja tagit) käyttöä varten Gitiin on lisätty vaihtoehtoinen tallennusmuoto "reftable". Reftable nopeuttaa viittauksien hakua sekä tarkistamista, että objektiin on olemassa viittaus.[73][74][75]

Ohjelmistotuki

Git integroituu useisiin ohjelmointiympäristöihin.[76][77][78] Microsoftin Visual Studio -kehitysympäristössä on tuki Git-versionhallinnalle.[79] libgit2 on linkitettävä kirjasto, jota voidaan käyttää muissa ohjelmissa Gitin ydintoiminnallisuudelle.[80]

Gitille on tehty useita graafisen käyttöliittymän sovelluksia.[81] Gitille on tehty myös SQL-rajapinta.[82] GitWeb on Gitin mukana tuleva verkkoselaimella käytettävä käyttöliittymä.[83] cgit on käytössä Linux-ytimen versiohallintapalvelimella.[84]

Tietovarastojen siirtämiseksi Subversionista Gitiin on olemassa muun muassa Eric S. Raymondin reposurgeon sekä git-svn työkalut.[85] Gitissä on eräitä valmiita komentoja tietojen hakemiseen muista järjestelmistä kuten Subversionista, Mercurialista, Bazaarista ja Perforcesta.[86][87]

VFS for Git

Microsoft on julkaissut Git Virtual File System (GVFS) -projektin laajojen projektien hallintaan.[88][89] Projekti mahdollistaa osan lähdekoodeista näkyvän virtuaalisesti osana tietovarastoa (repository) varsinaisen latauksen tapahtuessa kun tiedostoa tarvitsee käsitellä.[88]

Nimi muutettiin muotoon VFS for Git jotta se ei sekoitu GNOME-projektin GVFS:n kanssa.[90]

Käyttö

Eclipse Foundationin mukaan Git oli käyttäjäyhteisössä tehdyn kyselyn perusteella suosituin versionhallintajärjestelmä vuonna 2014.[91] RhodeCoden mukaan Git oli vuonna 2016 usealla eri mittaustavalla selkeästi suosituin versionhallintajärjestelmä.[92] StackOverflow:n kyselyssä vuonna 2018 Git oli selkeästi suosituin versionhallintajärjestelmä.[93]

Gitin suosion syiksi sanotaan seuraavia:[94]

  • hajautettu periaate helpottaa toimintaa heikkojen verkkoyhteyksien kanssa, eri aikavyöhykkeillä ja joustavampi työtapa: kyky toimia useiden tietovarastojen (engl. repository) kanssa
  • haarojen ja muutosten yhdistäminen tapahtuu hetkessä ja paikallisesti sekä kyky muistaa jo yhteen liitettyjä muutoksia
  • kokoontumisalue (engl. staging) mahdollistaa useiden muutoksien kokoamisen muutosjoukoksi
  • paras markkinointikampanja: Torvaldsilla on suuri vaikutus
  • GitHub levisi harrastekäytöstä ammattikäyttöön ja lisäsi sosiaalisen median ominaisuuksia

Gitiä on alettu vuoteen 2009 mennessä hyödyntää Linuxin ohella lukuisissa korkean profiilin ohjelmistohankkeissa kuten: Perl, GNOME, Qt, Samba, Kannettava tietokone jokaiselle lapselle ja Googlen Android-käyttöjärjestelmä. Vuonna 2020 GCC siirtyi käyttämään gitiä versiohallintaan.[95] Ars Technican mukaan Microsoft käyttää nykyisin Gitiä Windowsin lähdekoodien hallintaan.[96]

Hajautetun versionhallintajärjestelmän avulla kehitys on siirtynyt parempaan kehitysmalliin: Linux-ytimen kehitys on skaalautunut tuhansien ihmisten yhteiseen kehitystyöhön.[97]

Isännöintipalvelut

Gitiä käyttäviä lähdekoodin isännöintipalveluita on useita, joista suosituimpiin kuuluvat:[98]

Vastaavan palvelun Gitin kanssa voi aloittaa itse käyttämällä ohjelmistoja kuten Phabricator, Jenkins ja GitLabin ohjelmisto.[98][99]

Kritiikki

Gitiä on kritisoitu vaikeudesta, jota on parannettu kehittämällä työkaluja.[7][8] Vaikeuden on sanottu johtuvan joustavuudesta ja olevan joustavan järjestelmän synnynnäinen piirre.[100] Osa vaikeudesta on peräisin erilaisesta kokemustaustasta.[7]

Gitin mukana tulee suuri joukko työkaluohjelmia ja komentoja, joista pieni osa riittää normaalikäytössä.[97]

Julkaisut

Gitin julkaisuissa vX.Y.0 ovat ”ominaisuusversioita” ja vX.Y.Z ”ylläpitoversioita”.[101] Ennen Gitin versiota v1.9.0 vX.Y.Z olivat ”ominaisuusversioita” ja vX.Y.Z.W ”ylläpitoversioita”.[101]

Lähteet

  1. ↑ [ANNOUNCE] Git v2.47.0, (viitattu ). Tieto on haettu Wikidatasta.
  2. ↑ git github.com. Viitattu 27.2.2017.
  3. ↑ Linus Torvalds: License github.com. 17.1.2010. Viitattu 16.2.2015. (englanniksi)
  4. ↑ Linus Torvalds: Re: Kernel SCM saga.. marc.info. 7.4.2005. Viitattu 3.11.2019. (englanniksi)
  5. ↑ Linus Torvalds: Re: fatal: serious inflate inconsistency marc.info. 10.6.2007. Viitattu 3.11.2019. (englanniksi)
  6. ↑ a b A History of Version Control ericsink.com. Viitattu 23.2.2017.
  7. ↑ a b c d e f g h i j k l m 10 Years of Git: An Interview with Git Creator Linus Torvalds 6.4.2015. Linux Foundation. Arkistoitu 3.11.2019. Viitattu 3.11.2019. (englanniksi)
  8. ↑ a b c d e f g Zack Brown: A Git Origin Story 27.7.2018. Linux Journal. Viitattu 6.11.2019. (englanniksi)
  9. ↑ The kernel and BitKeeper part ways lwn.net. 6.4.2005. Viitattu 6.11.2019. (englanniksi)
  10. ↑ a b Linus Torvalds: Re: VCS comparison table marc.info. 19.10.2006. Viitattu 9.11.2019. (englanniksi)
  11. ↑ Linus Torvalds: Re: Kernel SCM saga.. marc.info. 7.4.2005. Viitattu 6.11.2019. (englanniksi)
  12. ↑ Linus Torvalds: Kernel SCM saga.. marc.info. 6.4.2005. Viitattu 6.11.2019. (englanniksi)
  13. ↑ a b The Monotone version control system lwn.net. Viitattu 6.11.2019. (englanniksi)
  14. ↑ a b Linus Torvalds: Re: Kernel SCM saga.. marc.info. 7.4.2005. Viitattu 6.11.2019. (englanniksi)
  15. ↑ a b Linus Torvalds: Re: [ANNOUNCE Git wiki] marc.info. 5.5.2006. Viitattu 9.11.2019. (englanniksi)
  16. ↑ Linus Torvalds: Re: Trivia: When did git self-host? marc.info. 27.2.2007. Viitattu 2.11.2019. (englanniksi)
  17. ↑ a b Matthew McCullough & Jon Loeliger: Chapter 1. Introduction (Version Control with Git, 2nd Edition) oreilly.com. ”Git immediately borrowed the idea from Monotone, according to Linus.” Viitattu 8.11.2019. (englanniksi)
  18. ↑ Linus Torvalds: First ever real kernel git merge! marc.info. 17.4.2005. Viitattu 2.11.2019. (englanniksi)
  19. ↑ Linux 2.6.12 marc.info. 17.6.2005. Viitattu 26.11.2019. (englanniksi)
  20. ↑ Linus Torvalds: Re: Mercurial 0.4b vs git patchbomb benchmark lkml.iu.edu. 29.4.2005. Viitattu 9.11.2019. (englanniksi)
  21. ↑ Linus Torvalds: Meet the new maintainer.. marc.info. 27.7.2005. Viitattu 2.11.2019. (englanniksi)
  22. ↑ git merriam-webster.com. Viitattu 7.3.2021. (englanniksi)
  23. ↑ Git FAQ git.wiki.kernel.org. Viitattu 7.3.2021. (englanniksi)
  24. ↑ After controversy, Torvalds begins work on "git" pcworld.idg.com.au. 20.4.2005. Arkistoitu 28.2.2021. Viitattu 7.3.2021. (englanniksi)
  25. ↑ Initial revision of "git", the information manager from hell · git/git@e83c516 GitHub. Arkistoitu 8.10.2017. Viitattu 21.1.2016.
  26. ↑ Linus Torvalds: Re: VCS comparison table marc.info. 18.10.2006. Viitattu 10.3.2020. (englanniksi)
  27. ↑ a b c Linus Torvalds: Re: more git updates.. marc.info. 10.4.2005. Viitattu 10.3.2020. (englanniksi)
  28. ↑ git-annotate git-scm.com. Viitattu 10.3.2020. (englanniksi)
  29. ↑ git-blame git-scm.com. Viitattu 10.3.2020. (englanniksi)
  30. ↑ a b Linus Torvalds: Re: impure renames / history tracking marc.info. 1.3.2006. Viitattu 10.3.2020. (englanniksi)
  31. ↑ Junio C Hamano: Re: Errors GITtifying GCC and Binutils marc.info. 24.3.2006. Viitattu 10.3.2020. (englanniksi)
  32. ↑ Junio C Hamano: Re: Errors GITtifying GCC and Binutils marc.info. 23.3.2006. Viitattu 10.3.2020. (englanniksi)
  33. ↑ Linus Torvalds: Re: git and bzr, on using git-blame to show code moved between source files marc.info. 28.11.2006. Viitattu 10.3.2020. (englanniksi)
  34. ↑ How do I add an empty directory to a git repository stackoverflow.com.
  35. ↑ a b c 1.3 Getting Started - What is Git? git-scm.com. Viitattu 3.11.2019. (englanniksi)
  36. ↑ 4.1 Git on the Server - The Protocols git-scm.com. Viitattu 10.3.2020. (englanniksi)
  37. ↑ 10.6 Git Internals - Transfer Protocols git-scm.com. Viitattu 13.3.2021. (englanniksi)
  38. ↑ a b 2.5 Git Basics - Working with Remotes git-scm.com. Viitattu 22.3.2021. (englanniksi)
  39. ↑ a b git-worktree git-scm.com. Viitattu 13.3.2021. (englanniksi)
  40. ↑ 10.2 Git Internals - Git Objects git-scm.com. Viitattu 10.3.2020. (englanniksi)
  41. ↑ 5.1 Distributed Git - Distributed Workflows git-scm.com. Viitattu 10.3.2020. (englanniksi)
  42. ↑ git-cherry-pick git-scm.com. Viitattu 23.9.2022. (englanniksi)
  43. ↑ a b 3.1 Git Branching - Branches in a Nutshell git-scm.com. Viitattu 10.3.2020. (englanniksi)
  44. ↑ git-checkout git-scm.com. Viitattu 13.3.2021. (englanniksi)
  45. ↑ git-switch git-scm.com. Viitattu 13.3.2021. (englanniksi)
  46. ↑ a b c d e 3.2 Git Branching - Basic Branching and Merging git-scm.com. Viitattu 13.3.2021. (englanniksi)
  47. ↑ a b 7.3 Git Tools - Stashing and Cleaning git-scm.com. Viitattu 13.3.2021. (englanniksi)
  48. ↑ a b git-merge git-scm.com. Viitattu 13.3.2021. (englanniksi)
  49. ↑ Elijah Newren: [PATCH 1/2 Change default merge backend from recursive to ort] lore.kernel.org. 4.8.2021. Viitattu 22.8.2021. (englanniksi)
  50. ↑ Taylor Blau: Highlights from Git 2.33 github.blog. 16.8.2021. Viitattu 17.8.2021. (englanniksi)
  51. ↑ 7.11 Git Tools - Submodules git-scm.com. Viitattu 10.3.2020. (englanniksi)
  52. ↑ git-submodule git-scm.com. Viitattu 10.3.2020. (englanniksi)
  53. ↑ a b c d e Managing Git projects with submodules and subtrees opensource.com. 6.5.2020. Viitattu 5.3.2021. (englanniksi)
  54. ↑ Git Subtree w3docs.com. Viitattu 5.3.2021. (englanniksi)
  55. ↑ Martin Owen: Git Submodules vs Git Subtrees martowen.com. Arkistoitu 1.3.2021. Viitattu 5.3.2021. (englanniksi)
  56. ↑ a b Torvalds, Linus: I thought I'd write an update on git and SHA1.. plus.google.com. Viitattu 27.2.2017.
  57. ↑ Migrate Git from SHA-1 to a stronger hash function. git-scm.com. Viitattu 23.9.2022. (englanniksi)
  58. ↑ Git team releases 2.25, takes step towards Perl freedom devclass.com. Viitattu 15.1.2020. (englanniksi)
  59. ↑ Git for Computer Scientists eagain.net. Viitattu 22.7.2021. (englanniksi)
  60. ↑ a b c d e f g h i Jonathan Corbet: A new hash algorithm for Git 3.2.2020. Lwn. (englanniksi)
  61. ↑ a b 7.4 Git Tools - Signing Your Work git-scm.com. Viitattu 4.3.2020. (englanniksi)
  62. ↑ Git repository access control wincent.com. 22.2.2010. Arkistoitu 14.9.2016. Viitattu 8.11.2019. (englanniksi)
  63. ↑ Frequently asked questions kernel.org. Viitattu 8.3.2020. (englanniksi)
  64. ↑ bzr/hg/git performance weblogs.mozillazine.org. 30.11.2006. Arkistoitu Viitattu 10.3.2020. (englanniksi)
  65. ↑ Oh what a relief it is digitalvampire.org. 16.11.2006. Viitattu 10.3.2020. (englanniksi)
  66. ↑ Giorgio Sironi: Git backups, and no, it's not just about pushing dzone.com. 18.5.2011. Viitattu 10.3.2020. (englanniksi)
  67. ↑ David Eisinger: Backup your Database in Git viget.com. 8.5.2009. Viitattu 10.3.2020. (englanniksi)
  68. ↑ git-fsck git-scm.com. Viitattu 18.7.2020. (englanniksi)
  69. ↑ 10.7 Git Internals - Maintenance and Data Recovery git-scm.com. Viitattu 18.7.2020. (englanniksi)
  70. ↑ Taylor Blau: Highlights from Git 2.34 github.blog. 15.11.2021. Viitattu 22.1.2022. (englanniksi)
  71. ↑ Derrick Stolee: Bring your monorepo down to size with sparse-checkout github.blog. 17.1.2020. Viitattu 22.1.2022. (englanniksi)
  72. ↑ Taylor Blau: Highlights from Git 2.25 github.blog. 13.1.2020. Viitattu 22.1.2022. (englanniksi)
  73. ↑ Taylor Blau: Highlights from Git 2.45 github.blog. 29.4.2024. Viitattu 3.5.2024. (englanniksi)
  74. ↑ reftable.txt github.com. Viitattu 3.5.2024. (englanniksi)
  75. ↑ Junio C Hamano: ANNOUNCE Git v2.45.0 lore.kernel.org. 29.4.2024. Viitattu 3.5.2024. (englanniksi)
  76. ↑ https://projects.eclipse.org/projects/technology.egit
  77. ↑ https://netbeans.org/kb/docs/ide/git.html (Arkistoitu – Internet Archive)
  78. ↑ https://www.jetbrains.com/help/idea/using-git-integration.html
  79. ↑ DevOps - Commit to Git: Source Control in Visual Studio 2015 Microsoft. Viitattu 27.2.2017.
  80. ↑ https://libgit2.org
  81. ↑ GUI Clients git-scm.com. Viitattu 6.11.2019. (englanniksi)
  82. ↑ https://github.com/src-d/gitbase
  83. ↑ 4.7 Git on the Server - GitWeb git-scm.com. Viitattu 10.3.2020. (englanniksi)
  84. ↑ Give Your Git Repository An Open Source Web Interface linux.com. 11.4.2016. Viitattu 10.3.2020. (englanniksi)
  85. ↑ The Debate Continues Over How To Transition GCC's SVN Repository To Git phoronix.com. Viitattu 17.12.2019. (englanniksi)
  86. ↑ 9.1 Git and Other Systems - Git as a Client git-scm.com. Viitattu 13.3.2021. (englanniksi)
  87. ↑ 9.2 Git and Other Systems - Migrating to Git git-scm.com. Viitattu 13.3.2021. (englanniksi)
  88. ↑ a b Microsoft Announces Git Virtual File-System (GVFS) phoronix.com. Viitattu 27.2.2017.
  89. ↑ Announcing GVFS (Git Virtual File System) Microsoft. Viitattu 27.2.2017.
  90. ↑ Microsoft Moves Ahead With Renaming "GVFS" Project To "VFS For Git" phoronix.com. 28.7.2018. Viitattu 18.7.2020. (englanniksi)
  91. ↑ Ian Skerrett: Eclipse Community Survey 2014 Results ianskerrett.wordpress.com. Viitattu 6.11.2019. (englanniksi)
  92. ↑ Version Control Systems Popularity in 2016 rhodecode.com. Viitattu 2.11.2019. (englanniksi)
  93. ↑ Developer Survey Results 2018 insights.stackoverflow.com. Viitattu 10.3.2020. (englanniksi)
  94. ↑ The impact of Git on software development codacy.com. 6.4.2018. Arkistoitu 2.11.2019. Viitattu 2.11.2019. (englanniksi)
  95. ↑ Joseph Myers: Re: git conversion in progress gcc.gnu.org. 13.1.2020. Viitattu 15.1.2020. (englanniksi)
  96. ↑ Microsoft hosts the Windows source in a monstrous 300GB Git repository Ars Technica. Viitattu 21.2.2017.
  97. ↑ a b Marti, Don: Linus on Linux: The Linus Torvalds Interview Part 2 ("Linus talks about the process of managing kernel developer commits, selecting a revision control system and how he personally uses git.") Linux Magazine. 26.4.2009. Arkistoitu Viitattu 28.4.2009. (englanniksi)
  98. ↑ a b Jason van Gumster: 6 places to host your git repository opensource.com. 30.8.2018. Viitattu 13.3.2021. (englanniksi)
  99. ↑ How to Run Your Own Git Server linux.com. 22.5.2018. Viitattu 13.3.2021. (englanniksi)
  100. ↑ Maxim Koretskyi: Becoming a Git pro. Part 1: internal Git architecture indepth.dev. 4.3.2020. Viitattu 10.3.2020. (englanniksi)
  101. ↑ a b How to maintain Git github.com. Viitattu 10.3.2020. (englanniksi)

Aiheesta muualla

Wikimedia Commonsissa on kuvia tai muita tiedostoja aiheesta Git.
Noudettu kohteesta ”https://fi.wikipedia.org/w/index.php?title=Git&oldid=22653399”