Википедија

Git

(преусмерено са Git (софтвер))

Git (транскр. гит) је систем контроле верзија за праћење промена у рачунарским фајловима и за координисан рад више људи на тим фајловима. Примарно се користи за верзионисање кода при развоју софтвера,[5] али се може користити за праћење промена у било којим фајловима. То је дистрибуирани систем контроле верзија чија је главна предност брзина,[6] интегритет података, [7] и подршка за дистрибуиране, нелинеарне послове.[8]

Git
Оригинални аутор(и)Линус Торвалдс[1]
Програмер(и)Јунио Хамано и други[2]
Прво издање7. април 2005. год.; пре 19 година (2005-04-07)
Стабилно издање
2.44.0 / 23. фебруар 2024. год.; пре 55 дана (2024-02-23)
Репозиторијум
Уреди на Википодацима
Написан у
Оперативни систем
Платформа
Доступан наенглески
ТипСистем контроле верзија
ЛиценцаGNU GPLv2[3] и GNU GPLv2.1[4]
Веб-сајтgit-scm.com

Гит је развио Линус Торвалдс, 2005. године за потребе развоја Линукс језгра, уз допринос и других програмера језгра његовом првобитном развоју.[9] Његов тренутни развијач, од 2005. године је Јунио Хамано.

Као и код већине других дистрибуираних система контроле верзија, а за разлику од већине клијент-сервер система, сваки Гит радни директоријум, на сваком рачунару представља комплетан репозиторијум са комплетном историјом и употпуњеном могућношћу за праћење верзија, независно од приступа мрежи или централног сервера.[10]

Гит је слободан софтвер дистрибуиран под условима ГНУ-ове опште јавне лиценце верзије 2.

Историја уреди

Развој Гит-а је почео у априлу 2005. године, након што је много програмера Линукса препустило приступ БитКипер-у, власничком систему за изворну контролу управљања (енгл. source control management - SCM) који се раније користио за одржавање пројекта.[11] Носилац ауторских права над БитКипер-ом, Лари МекВој, је повукао бесплатно коришћење производа, тврдећи да је Ендру Тридгел имао обрнуто-пројектоване протоколе за БитКипер.[12]

Линус Торвалдс је хтео дистрибуирани систем који би могао користити као БитКипер, али ниједан од доступних слободних система није задовољавао његове потребе, посебно у смислу перформанси. Торвалдс је узео за пример систем за изворну контролу управљања коме је требало тридесет секунди да примени закрпу и ажурира све повезане метаподатке, и напоменуо да то не би одговарало потребама развоја Линукс језгра, где ће синхронизација са осталим извршавањима захтевати 250 таквих акција у тренутку. Хтео је да крпљење траје три секунде,[6] и имао је неколико других критеријума у виду:

  • узмимо систем конкурентног верзионисања (енгл. Concurrent Versions System - CVS) као пример шта не треба радити; ако сте у недоумици, донесите супротну одлуку[8]
  • подржава дистрибуирани процес рада, налик БитКипер-овом[8]
  • веома јаке гаранције против корупције, било случајне или злонамерне.[7]

Ова три критеријума су елиминисала све системе за контролисање верзија који су постојали у том периоду, осим Монотон-а. Разматрање перформанси је искључило и ову верзију.[8] Одмах након објаве 2.6.12-рц2 развојне верзије Линукс језгра,[8] Торвалдс је одлучио да напише свој систем.[8]

Торвалдс се нашалио око назива git, који у сленгу Британског Енглеског значи "непријатно лице". Торвалдс је рекао: "Ја сам егоистично копиле, и назваћу све моје пројекте по себи. Први је био 'Линукс', а сада 'гит'."[13][14] У упутству се Гит описује као "глупи трагач садржаја".[15] У "readme" фајлу изворног кода се још више говори о томе:[16]


Назив "гит" је дао Линус Торвалдс када је написао прву верзију. Он је описао овај алат као "глупи прикупљач садржаја" а назив као (у зависности од расположења):

  • насумучну комбинацију три слова која може да се изговори, а није заправо искоришћена за неку Јуникс команду. Чињеница да је то погрешно изговорена реч "get" није релевантна.
  • глупо, одвратно и презирно. једноставно. Изабери било коју реч из речника сленга.
  • "глобални прикупљач информација": расположени сте, и он заправо ради за вас. Анђеоски глас и светло, одједном испуњавају просторију
  • "g*dd*mn idiotic truckload of sh*t": када се поквари

Развој Гит-а је почео 3. априла 2005. године.[17] Пројекат је објављен 6. априла,[18] и постао селф-хостинг од 7. априла.[17] Прво спајање више грана је учињено 18. априла.[19] Торвалдс је постигао своје циљеве; 29. априла, новонастали Гит је био упоређиван са снимљеним закрпама Линукс језгра три по стопи од 6,7 секунди.[20] Дана 16. јуна Гит је достигао издање 2.6.12 језгра.[21]

Торвалдс је предао одржавање Гит-а 26. јула 2005. Јуниу Хаману, главном сараднику на пројекту.[22] Хамано је био одговоран за пуштање верзије 1.0, 21. децембра 2005. године, и остао је главни одржавалац пројекта.[23]

Верзија Првобитни датум објаве Последња верзија Датум објаве
0.99 2005-07-11 0.99.9n 2005-12-15
1.0 2005-12-21 1.0.13 2006-01-27
1.1 2006-01-08 1.1.6 2006-01-30
1.2 2006-02-12 1.2.6 2006-04-08
1.3 2006-04-18 1.3.3 2006-05-16
1.4 2006-06-10 1.4.4.5 2008-07-16
1.5 2007-02-14 1.5.6.6 2008-12-17
1.6 2008-08-17 1.6.6.3 2010-12-15
1.7 2010-02-13 1.7.12.4 2012-10-17
1.8 2012-10-21 1.8.5.6 2014-12-17
1.9 2014-02-14 1.9.5 2014-12-17
2.0 2014-05-28 2.0.5 2014-12-17
2.1 2014-08-16 2.1.4 2014-12-17
2.2 2014-11-26 2.2.3 2015-09-04
2.3 2015-02-05 2.3.10 2015-09-29
2.4 2015-04-30 2.4.10 2015-09-29
2.5 2015-07-27 2.5.4 2015-09-29
2.6 2015-09-28 2.6.5 2016-01-04
2.7 2015-10-04 2.7.3 2015-10-30
2.8 2016-03-28 2.8.4 2016-06-06
2.9 2016-06-13 2.9.3 2016-08-12
2.10 2016-09-02 2.10.2 2016-10-28
2.11 2016-11-29 2.11.1 2017-02-02
2.12 2017-02-24 2.12.0 2017-02-24

Дизајн уреди

Гит-ов дизајн је инспирисан БитКипер-ом и Монотон-ом.[24][25] Гит је првобитно замишљен као машина ниског нивоа система контроле верзија који су други могли написати као предњи крај, као што је Когито или СтГИТ.[25] Језгро Гит пројекта је од тада постало комплетан систем контроле верзија који се употребљивао директно.[26] Иако је био под снажним утицајем БитКипер-а, Торвалдс је намерно избегавао уобичајене приступе, што је довело до јединственог дизајна.[27]

Карактеристике уреди

Гит-ов дизајн је синтеза Торвалдсовог искуства са Линуксом у одржавању великих дистрибуираних развојних пројеката, заједно са својим властитим знањем о перформансама система датотека добијеног из истог пројекта као и хитне потребе да произведе систем који ради, у кратком року. Ови услови су довели до следећих избора за имплементацију:

Јака подршка за нелинеарни развој
Гит подржава брзо гранање и спајање, и укључује посебне алате за визуализацију и усмеравање историје нелинеарних развоја. Главна претпоставка у Гит-у је та да ће промена бити много чешће спајана него што је написано, јер је прошао кроз прсте разних критичара. У Гиту су грана веома једноставне: грана је само референца ка једном комит-у. Са својим надређеним комитом, цела структура гране се може креирати.
Дистрибуирани развој
Као Даркс, БитКипер, Меркуријал, СВК, Базар и Монотон, Гит даје сваком програмеру локалну копију целокупне историје развоја, а промене се копирају из једног репозиторијума у друго. Ове промене се увозе као додатне развојне гране, и могу се и спојити на исти начин као и локално развијене гране.
Компатибилност са постојећим системима/протоколима
Репозиторијуми се могу објавити преко HTTP-а, ФТП-а, rsync-а, или Гит протокола преко било којег сокета, или ssh. Гит такође има CVS сервер емулацију, која омогућава коришћење постојећих CVS клијената и IDE додатака за приступ Гит-овим репозиторијумима. Субверзија и SVK репозиторијуми се могу користити директно са git-svn-ом.
Ефикасно руковођење великим пројектима
Торвалдс је описао Гит као веома брз и прилагодљив,[28] а Мозилини тестови перформанси су[29] показали да је за ред величине бржи од неких система za контролу верзија, а преузимање верзије историје из локалног репозиторијума може бити и до сто пута брже од преузимања са удаљеног сервера.[30]
Криптографска провера идентитета историје
Историја Гит-а се чува на такав начин да идентификација посебне верзије (комит на језику Гит-а) зависи од комплетне историје развоја која је довела до тог комита. Од тренутка када је верзија објављена, више је није могуће мењати неприметно. Структура је слична Меркеловом стаблу, али са додатним подацима на чворовима и листовима.[31] (Меркуријал и Монотон такође имају овакво својство.)
Дизајн базиран на алатима
Гит је осмишљен као скуп програма писаних у Ц-у, као и скуп скрипти које представљају допуну тих програма.[32] Иако је већина тих скрипти написана у C-у због брзине и преносивости, дизајн је остао исти, а и лако је било повезати компоненте заједно.[33]
Стратегије прикључног спајања
Као део свог дизајна налик алату, Гит има добро дефинисан модел недовршеног спајања, и има већи број алгоритама који могу да потпомогну у том сегменту, што је кулминирало тиме да је саопштавао кориснику да није у стању да аутоматски комплетира спајање и да је потребно ручно изменити.
Смеће се нагомилава уколико није сакупљено
Прекидање операција или опозивање промена ће оставити велики број бескорисних објеката у бази података. То су углавном мали делићи историје објеката који су у сталном порасту. Гит ће аутоматски обављати сакупљање смећа када се непотребни предмети прикупе у репозиторијуму. Смеће се може експлицитно позвати коришћењем git gc --prune.[34]
Периодично експлицитно слагање објеката
Гит чува сваки новонастали објекат као посебан фајл. Иако је појединачно компресован, он заузима много поростора и врло је неефикасан. Овај проблем је решен стварањем пакета који складиште велики број објеката у једној датотеци (или проток мрежних бајтова) по имену packfile, који је делта-компресован. Пакети су компресовани коришћењем хеуристике по којој су фајлови са истим именом вероватно слични. Одговарајући индекс фајл се креира за сваки packfile, и обележава сваки објекат у њему. Нови објекти (новостворена историја) се и даље чувају појединачно, и периодично препакивање је неопходно ради одржавања ефикасности простора. Процес паковања репозиторијума може бити веома скуп. Дозволом да објекти постоје у репозиторијуму за непотрегне фајлове, али у брзо произведеном формату, Гит омогућава да рад са скупим пакетима буде одложен за касније, када време није битно (нпр. на крају радног дана). Гит врши аутоматско периодично препаковање, али је и за кориснике препакивање могуће уз помоћ команде git gc. Због целости података, и packfile и његов индекс имају SHA-1 контролни збир у себи, а њега такође садржи и име датотеке. Да бисте проверили интегритет, покрените команду git fsck.

Још једна особина Гит-а је да је снима гранање директоријума фајлова. Најранији системи за контролу изворног кода (енгл. Source Code Control System - SCCS) и системи за контролу ревизија (енгл. Revision Control System - RCS), радили су на појединачним фајловима и омогућавали уштеду простора стеченог од прошараних делти (SCCS) или делта кодирања (RCS) (углавном сличних) верзија. Каснија ревизија контролних система довела је до тога да је фајл имао идентитет кроз више ревизија пројекта. Међутим, Торвалдс је одбацио овај концепт.[35] Сходно томе, Гит не снима експлицитно ревизије односа на било ком нивоу испод гране изворног кода.

Односи имплицитних ревизија имају неке значајне последице:

  • Знатно је скупље извршити промену целе историје једног фајла него цео један пројекат.[36] Да би добили историју промена које утичу на дату датотеку, Гит мора да прође кроз глобалну историју, а онда и да утврди да ли свака промена модификује тај фајл. Овај метод прегледа историје, међутим, даје Гит-у могућност да производи са једнаком ефикасношћу једну историју која приказује промене на произвољан скуп датотека. На пример, поддиректоријум изворног стабла плус повезано глобално заглавље датотеке је врло чест случај.
  • Преименовање се чешће врши имплицитно него експлицитно. Заједнички приговор CVS-а је да он користи назив датотеке како би идентификовао своју историју ревизија, па премештање или преименовање фајла није могуће без прекидања своје историје, или преименовања историје што би направило историју нетачном. Већина система контроле ревизија после CVS-а решава овај ппоблем давањем јединственог имена датотеци (аналогно и-нод броју) на кога не утиче преименовање. Гит не подржава такав идентификатор, а за то се тврди да је предност.[37][38] Фајлови изворног кода су понекад раштркани, спојени или просто преименовани,[39] па би њихово представљање као једноставна преименовања, замрзнуло нетачан опис онога што се догодило у (непроменљивој) историји. Гит чешће препознаје грешке детектовањем промене имена приликом претраживања историје снимака него снимањем исте када прави снимак.[40] (Укратко, ако је фајл у некој N ревизији, фајлови са истим именом у ревизији N-1 представљају његове подразумеване претке. Међутим, када не постоји као назив датотеке у ревизији N-1, Гит тражи фајл који је постојао само у ревизији N-1 и који је веома сличан новом фајлу.) Међутим, то захтева знатно интензивнији рад процесора сваки пут кад се прегледа историја и неколико опција како би се подесила хеуристика. Овај механизам не функционише увек; понекад, фајл који је преименован са променама, у истом комиту се чита као брисање старе датотеке и води ка стварању новог фајла. Програмери могу да раде око овог ограничења комитовањем преименовања и измена одвојено.

Гит подржава неколико стратегија спајања; неподразумева се може изабрати у тренутку спајања:[41]

  • resolve: традиционални алгоритам спајања на три начина
  • recursive: ово је подразумевана опција приликом повлачења или спајања једне гране и то је варијанта алгоритма спајања на три начина.

    Када постоји више од једног заједничког претка који могу да се користе за спајање на три начина, оно креира спојено стабло заједничких предака и то користи као референтно стабло за спајање на три начина. Као резултат овога, пријављено је много мање конфликта при спајању, без настанка међуспајања у урађеним тестовима на спојеним комитима, у историји развоја Линукс 2.6 језгра. Такође, ово може да открије и рукује спајањима које укључују преименовања.

    — Линус Торвалдс[42]
  • octopus: ово је подразумевана опција приликом спајања две или више глава.

Структуре података уреди

Гит-ове примитиве нису инхерентно систем за изворну контролу управљања. Торвалдс објашњава,[35]

На много начина се гит може посматрати као систем фајлова - он има могућност адресирања садржаја, верзионисања, али сам га ја заиста дизајнирао да приступи проблему са становишта система фајлова као особе (хеј, ја се бавим језгрима)и у ствари имам нулту толеранцију у креирању традиционалних система за изворну контролу управљања.

Од овог иницијалног дизајна, Гит је развио комплетан сет функција које се очекују од традиционалног система за изворну контролу управљања,[26] са функцијама углавном створених по потреби, уместо уређиваних и прошириваних током времена.

 
Неки токови података и нивои складиштења у систему контроле Гит верзија.

Гит има две структуре података: променљив индекс (који се још назива и фаза или кеш) који кешира информације о радном директоријуму и комитовању наредне ревизије; и непроменљив, у коме се само додају објекти у базу података.

Индекс служи као веза између објекта базе података и радног стабла.

Објекат базе података садржи четири врсте објеката:

  • БЛОБ (бинарни велики објекат) је садржај датотеке. БЛОБ-ови немају име датотеке, временске ознаке, нити друге метаподатке. (Назив блоба интерно је хеш сопственог садржаја.)
  • Стабло објекат је еквивалент директоријуму. Оно садржи списак имена фајлова, сваки са неким типом бита и име БЛОБ-а или стабла објекта који чине тај фајл, симболички линк или садржај директоријума. Овај објекат описује снимак изворног стабла.
  • Комит објекат повезује стабло објекат заједно у историју. Он садржи назив стабла објекта (највишег извора у директоријуму), временску ознаку, евиденцију порука и имена нула или више надређених комит објеката.
  • Ознака објекат је контејнер који садржи референцу на други објекат и може да прими додатне мета податке који се односе на други предмет. Најчешће се користи за складиштење дигиталних потписа за комит објекте који одговарају одређеним верзијама података који су праћени од стране Гит-а.

Сваки објекат се идентификује SHA-1 хешом његовог садржаја. Гит израчунава хеш, и користи ову вредност за име објекта. Објекат се ставља у директоријум који се подудара са прва два слова његовог хеша. Остатак хеша се користи као име фајла за тај објекат.

Гит чува сваку ревизију датотеке као јединствени блоб. Односи између блобова се могу наћи путем испитивања стабла и комит објеката. Недавно додати објекти су смештени у целини помоћу злиб компресије. Ово може заузети доста простора на диску за кратко време, тако да предмети могу да се комбинују у пакете, који користе делта компресију како би штедели простор, складиштење блобова као и њихове промене у односу на друге блобове.

Гит сервери се обично слушају на TCP порту 9418.[43]

Референце уреди

Сваки објекат у Гит бази података који се не односи на њега се може очистити помоћу команде garbage collection, или аутоматски. Објекат може бити референциран од стране другог објекта, или експлицитно референциран. Гит препознаје различите врсте референци. Команде за креирање, премештање и брисање референци варирају. "git show-ref" листа наводи све референце. Неке врсте су:

  • heads: односи се на локални објекат.
  • remotes: односи се на објекат који постоји у удаљеном репозиторијуму .
  • stash: односи се на објекат који још није извршен.
  • meta: на пример. конфигурација у репозиторијуму, корисничка права. refs/meta/config именски простор је увео Герит (софтвер)[44]
  • tags: видети изнад.

Имплементације уреди

 
gitg је графички корисник GTK+

Гит је првенствено развијен на Линуксу, иако подржава већину главних оперативних система, укључујући BSD, Соларис, OS X и Microsoft Windows.[45]

Први Microsoft Windows "порт" за Гит је, пре свега, Линуксова емулација фрејмворка који хостује Линукс верзију. Инсталирање Гит-а под Windows-ом креира сличан Program Files директоријум који садржи 5.236 датотека у 580 директоријума. Ово укључује MinGW порт ГНУ-ове колекције компајлера, Perl 5, msys2.0 (Cygwin форк, емулациони фрејмворк за Windows налик Јуниксу) и разне друге Windows портове или емулаторе из помоћних библиотека Линукса. Тренутне нативне верзије за Windows се дистрибуирају као 32-битне и 64-битне инсталације.

JGit имплементација Гит-а је Јава библиотека, дизајнирана да буде уграђена у било којој Јава апликацији. JGit се користи у Герит алату за проверу кода и EGit, Гит клијент за Еклипс окружење.[46]

Dulwich имплементација Гит-а је чиста Пајтонова софтверска компонента за Пајтон 2.[47]

libgit2 имплементација Гит-а је ANSI C софтверска библиотека, која може бити изграђена на више платформи, укључујући Microsoft Windows, Линукс, Мек OS X, и BSD.[48] Везана је за многе програмске језике, укључујући Руби, Пајтон и Хаскел.[49][50][51]

JS-Git је Јаваскрипт имплементација која представља подскуп Гит-а.[52]

Гит сервер уреди

Пошто је Гит дистрибуирани систем контроле верзија, он се може користити као самостални сервер. Посвећени Гит серверски софтвер помаже, поред осталих карактеристика, при додавању контролог приступа, и приказује садржај Гит-овог репозиторијума путем веба, а помаже и приликом организовања већег броја репозиторијума.

Даљинско складиштење фајлова и приступ преко љуске
Гит репозиторијум може да се клонира у заједнички систем датотека, а могу му приступати и друге особе. Такође му се може приступити преко даљинске љуске уз инсталацију Гит-овог софтвера који омогућава кориснику да се пријави.[53]
Гит демон, аутоматски-веб
Гит демон (енгл. Git daemon) омогућава корисницима да деле свој репозиторијум колегама. Гит аутоматски-веб омогућава корисницима да обезбеде веб преглед неког репозиторијума. Од априла 2014. године аутоматски-веб не ради на Windows-у. Оба се могу видети у линији Меркуријалове "ХГ услуге".[54][55]
Гитолит
Гитолит (енгл. Gitolite) је облик контроле приступа у оквиру Гит-а, који пружа солидну контролу приступа Гит-овим репозиторијумима. Уз помоћ других софтвера он може да има даљински увид у репозиторијуме на серверу.[56][57]
Апач Алура
Апач Алура (енгл. Apache Allura) је развијени софтвер отвореног кода за управљање репозиторијумима слободног кода, извештавање о баговима, дискусије, вики странице, блогове и више за било које појединачне пројекате.
Герит
Герит (енгл. Gerrit) обезбеђује две од три функционалности: контролу приступа и управљање репозиторијумом. Користи jGit. Увид у репозиторијум је повезан нпр. или са Гитолит-ом или Гитблит-ом.
Гитблит
Гитблит (енгл. Gitblit) омогућава све три функције, али се у већим инсталацијама користи као претраживач репозиторијума који је инсталиран заједно са Герит-ом ради контроле приступа и управљања репозиторијумом.[58][59]

Гитблит такође може да обезбеди опцију синхронизације за друге репозиторијуме.

Гитилс
Гитилс (енгл. Gitiles) је једноставан претраживач репозиторијума, који се најчешће користи заједно са Герит-ом.[60][61]
Бонобо Гит сервер
Бонобо Гит Сервер (енгл. Bonobo Git Server) је једноставан Гит сервер за Windows имплементације као што је АСП.НЕТ капија.[62] Он се ослања на механизме заштите које пружа Windows Интернет информациони сервис, тако да не подржава SSH приступ, али се лако може повезати са активним директоријумом.
Гиториус
Гиториус (енгл. Gitorious) је слободан софтвер иза Гит-овог сервиса за прављење репозиторијума истог имена. У марту 2015, Гиториус је купио ГитЛаб.[63]
ГитЛаб
ГитЛаб (енгл. GitLab) пружа услуге софтверског репозиторијума. Он омогућава интернет интерфејс као што је ГитХаб, а написан је у Руби-ју.
Гогс
Гогс (енгл. Gogs) је још један Гит сервис, написан у Гоу. Пружа сличне функције ГитХаб-у као веб интерфејс.[64]
ГитХaб
ГитХаб (енгл. GitHub) је веб-базиран складишни хостинг сервис на коме можете поставити копију свог Гит репозиторијума. То је Гит-ов сервис за прављење репозиторијума, који нуди све функције дистрибуирану контролу ревизија и менаџмент изворног кода, додајући своје карактеристике. За разлику од Гит-а, који је стриктно алат који се користи из командне линије, ГитХаб пружа веб-базиран графички интерфејс, радну површину и мобилну интеграцију. Такође пружа контролу приступа и неколико функција за сарадњу, као што су праћење грешака (енгл. bug tracking), захтеве за додавање нових карактеристика (енгл. feature request), управљање задацима (енгл. task management) и могућност прављења вики документације за сваки пројекат. Он омогућава и да сарађујете са другим људима на пројекту. ГитХаб то ради тако што омогућава централизовану локацију која дели репозиторијуме, веб-заснован интерфејс који то надгледа и функције као што је форковање, а повлачи захтеве дистрибуираних система контроле верзија, проблеме (багове) и викије.
Битбакет
Битбакет (енгл. Bitbucket) је сервис заснован на вебу за пројекте који користе или Гит (од октобра 2011) или Меркуријал (од лансирања) система контроле верзија. Битбакет нуди и комерцијалне планове и бесплатне налоге.
Сорсграф
Сорсграф (енгл. Sourcegraph) је Гит-ов сервис, написан у Гоу. Он такође пружа дефинисање, упућивање, и функцију семантичког претраживача (кроз анализу кода у неколико језика).[65]
Комерцијални производи
Комерцијални производи су такође доступни за инсталацију у облику програма, међу њима су ГитХаб софтвер (који за основу користи Гит), Стеш (који користи прилагођени приказ и основни Гит у позадини), Team Foundation Server (користи ligBit2).[66]

Усвајање уреди

Еклипс фондација је пријавила у свом годишњем истраживању да је од маја 2014. године, Гит најраспрострањенији алат за управљање изворним кодом, где 42,9% професионалних програмера наглашава да користи Гит као њихов примарни систем контроле извора, у поређењу са 36,3% у 2013. години, 32% у 2012. години; искључујући коришћење ГитХуб-а: 33.3% у 2014. години, 30,3% у 2013. години, 27,6% у 2012. и 12,8% у 2011. години.[67] Директоријум отвореног кода Black Duck Open Hub извештава сличан однос међу пројектима отвореног кода.[68]

Британски веб-сајт за послове у области информационих технологија itjobswatch.co.uk извештава да се од краја септембра 2016. године, 29.27% од свих отворених конкурса на позиције за развој софтвера у Великој Британији наводе Гит,[69] испред 12,17% за Мајкрософтов Team Foundation Server,[70] 10.6% за Apache Subversion,[71] 1.3% за Меркуријал,[72] и 0,48% за Visual SourceSafe.[73]

Сигурност уреди

Гит не обезбеђује контролне механизме приступа, али је пројектован за операције са другим алатима који су специјализовани за контролу приступа.

Дана 17. децембра 2014. године, откривена је злоупотреба Microsoft Windows и Мекове верзије Гит клијента. Нападач је могао да изврши арбитрарно извршавање кода на Windows-ом или Мек рачунару са инсталираним Гит-ом и тако ствара злонамерно Гит стабло (директоријум) по имену .git (директоријум у Гит-овим репозиторијумима који чува све податке у самом репозиторијуму) у другом случају би (као што су .GIT или .Git, је било потребно зато што Гит не дозвољава да се верзије са свим малим словима .git стварају ручно) стварао заражене датотеке у .git/hooks директоријуму (фолдер са извршним датотекама које Гит проналази) у репозиторијуму како би нападач могао да модификује репозиторијум. Ако би Windows или Мек корисници "повукли" (преузели) верзију репозиторијума са зараженим директоријумом, а затим је пребацили у свој директоријум, .git директоријум би био преписан (због величине слова у Windows и Мек системима датотека) и заражени фајлови у .git/hooks се могу покренути, што води ка томе да се нападачеве команде аутоматски извршавају. Нападач такође може модификовати датотеке са подешавањима .git/config, које омогућавају нападачу да створи заражене Гит алиасе (алиас-е за Гит-ове команде или спољне команде) или измени постојеће псеудониме како би покренуо заражене команде. Овај недостатак је отклоњен у верзији 2.2.1 Гит-а, објављеној 17. децембра 2014. године, и најављеној следећег дана.[74][75]

Верзија Гит-а 2.6.1, објављена 29. септембра 2015. године, је садржала закрпе за сигурносну рањивост (CVE-2015-7545)[76] које су омогућавале арбитрарно покретање кода.[77] Ова рањивост је могла да се искористи када би нападач убедио мету да клонира одређену УРЛ адресу, јер су неке команде уграђене у самом УРЛ-у.[78] Нападач би могао то да искористи помоћу M-I-T-M-A напада уколико би повезивање било не-енкриптовано, [78] јер би могао да преусмери корисника на одређени УРЛ. Рекурзивни клонови су били такође угрожени, јер су дозвољавали да контролор репозиторијума прецизира произвољне УРЛ адресе преко датотеке gitmodules.[78]

Гит користи SHA-1 хешеве интерно. Линус Торвалдс наводи да се хеш највише користи за заштиту од неочекиваног квара.

Види још уреди

Референце уреди

  1. ^ „Initial revision of "git", the information manager from hell”. Github. 8. 04. 2005. Приступљено 20. 12. 2015. 
  2. ^ „Commit Graph”. Github. 8. 06. 2016. Приступљено 19. 12. 2015. 
  3. ^ „Git's GPL license at github.com”. github.com. 18. 01. 2010. Приступљено 12. 10. 2014. 
  4. ^ „Git's LGPL license at github.com”. github.com. 20. 05. 2011. Приступљено 12. 10. 2014. 
  5. ^ Scopatz, Anthony; Huff, Kathryn D. (2015). Effective Computation in Physics. O'Reilly Media, Inc. стр. 351. ISBN 9781491901595. Приступљено 20. 04. 2016. 
  6. ^ а б Torvalds, Linus (7. 04. 2005). „Re: Kernel SCM saga..”. linux-kernel (Листа адреса).  "So I'm writing some scripts to try to track things a whole lot faster."
  7. ^ а б Torvalds, Linus (10. 06. 2007). „Re: fatal: serious inflate inconsistency”. git (Листа адреса). 
  8. ^ а б в г д ђ Linus Torvalds (3. 05. 2007). Google tech talk: Linus Torvalds on git. Корисна информација се налази на: 02:30. Приступљено 16. 05. 2007. 
  9. ^ „A Short History of Git”. Pro Git (2nd изд.). Apress. 2014. Приступљено 26. 12. 2015. 
  10. ^ Chacon, Scott (24. 12. 2014). Pro Git (2nd изд.). New York, NY: Apress. стр. 29—30. ISBN 978-1-4842-0077-3. 
  11. ^ „BitKeeper and Linux: The end of the road? | linux.com”. Archive09.linux.com. Архивирано из оригинала 04. 03. 2016. г. Приступљено 9. 1. 2016. 
  12. ^ McAllister, Neil (2. 05. 2005). „Linus Torvalds' BitKeeper blunder”. InfoWorld. IDG. Приступљено 8. 09. 2015. 
  13. ^ "GitFaq: Why the 'git' name?"
  14. ^ "After controversy, Torvalds begins work on 'git'" Архивирано на сајту Wayback Machine (1. фебруар 2011).
  15. ^ "git(1) Manual Page".
  16. ^ "Initial revision of "git", the information manager from hell · git/git@e83c516".
  17. ^ а б Torvalds, Linus (27. 02. 2007). „Re: Trivia: When did git self-host?”. git (Листа адреса). 
  18. ^ Torvalds, Linus (6. 04. 2005). „Kernel SCM saga..”. linux-kernel (Листа адреса). 
  19. ^ Torvalds, Linus (17. 04. 2005). „First ever real kernel git merge!”. git (Листа адреса). 
  20. ^ Mackall, Matt (29. 04. 2005). „Mercurial 0.4b vs git patchbomb benchmark”. git (Листа адреса). 
  21. ^ Torvalds, Linus (17. 06. 2005). „Linux 2.6.12”. git-commits-head (Листа адреса). 
  22. ^ Torvalds, Linus (27. 07. 2005). „Meet the new maintainer...”. git (Листа адреса). 
  23. ^ Hamano, Junio C. (21. 12. 2005). „Announce: Git 1.0.0”. git (Листа адреса). 
  24. ^ Torvalds, Linus (2006-05-05).
  25. ^ а б Torvalds, Linus (2005-04-08).
  26. ^ а б Torvalds, Linus (2006-03-23).
  27. ^ Torvalds, Linus (2006-10-20).
  28. ^ Torvalds, Linus (2006-10-19).
  29. ^ Jst's Blog on Mozillazine "bzr/hg/git performance".
  30. ^ Dreier, Roland (2006-11-13).
  31. ^ "Trust".
  32. ^ Torvalds, Linus.
  33. ^ iabervon (2005-12-22).
  34. ^ "Git User's Manual". 2007-08-05.
  35. ^ а б Torvalds, Linus (2005-04-10).
  36. ^ Haible, Bruno (2007-02-11). "how to speed up "git log"?". git (Mailing list).
  37. ^ Torvalds, Linus (2006-03-01).
  38. ^ Hamano, Junio C. (2006-03-24).
  39. ^ Hamano, Junio C. (2006-03-23).
  40. ^ Torvalds, Linus (2006-11-28).
  41. ^ Torvalds, Linus (2007-07-18). "git-merge(1)".
  42. ^ Torvalds, Linus (18. 07. 2007). „CrissCrossMerge”. Архивирано из оригинала 13. 01. 2006. г. Приступљено 15. 03. 2017. 
  43. ^ "1.4 Getting Started – Installing Git". http://git-scm.com.
  44. ^ „Gerrit Code Review – Project Configuration File Format”. Gerrit-review.googlesource.com. Приступљено 9. 1. 2016. 
  45. ^ "downloads".
  46. ^ "JGit".
  47. ^ "Dulwich".
  48. ^ "libgit2".
  49. ^ "rugged".
  50. ^ "pygit2".
  51. ^ "hlibgit2".
  52. ^ https://github.com/creationix/js-git "js-git: a JavaScript implementation of Git."
  53. ^ 4.4 Git on the Server – Setting Up the Server, Pro Git.
  54. ^ „hosting a Git repository on windows”. Архивирано из оригинала 07. 01. 2015. г. Приступљено 08. 01. 2016. 
  55. ^ „git-instaweb manual page”. Git-scm.com. Приступљено 9. 1. 2016. 
  56. ^ „Hosting git repositories”. Gitolite.com. Приступљено 9. 1. 2016. 
  57. ^ „gitolite source code and description”. Github.com. Приступљено 9. 1. 2016. 
  58. ^ „Gitblit Homepage”. Gitblit.com. 23. 11. 2015. Приступљено 9. 1. 2016. 
  59. ^ „Wikimedia Gitblit installation”. Git.wikimedia.org. Приступљено 9. 1. 2016. 
  60. ^ „Gitiles Homepage”. Code.google.com. Приступљено 9. 1. 2016. 
  61. ^ „Android source code repositories”. Android.googlesource.com. Приступљено 9. 1. 2016. 
  62. ^ Bonobogit
  63. ^ "GitLab acquires Gitorious to bolster its on premises code collaboration platform".
  64. ^ "Gogs: A painless self-hosted Git service." http://gogs.io/
  65. ^ "Sourcegraph: the intelligent, hackable code host." https://sourcegraph.com/
  66. ^ "Microsoft embraces git with new TFS support, Visual Studio integration".
  67. ^ "Results of Eclipse Community Survey 2012".
  68. ^ "Compare Repositories – Open Hub".
  69. ^ „Git (software) Jobs, Average Salary for Git Distributed Version Control System Skills”. Itjobswatch.co.uk. Приступљено 30. 09. 2016. 
  70. ^ „Team Foundation Server Jobs, Average Salary for Microsoft Team Foundation Server (TFS) Skills”. Itjobswatch.co.uk. Приступљено 30. 09. 2016. 
  71. ^ „Subversion Jobs, Average Salary for Apache Subversion (SVN) Skills”. Itjobswatch.co.uk. Приступљено 30. 09. 2016. 
  72. ^ „Mercurial Jobs, Average Salary for Mercurial Skills”. Itjobswatch.co.uk. Приступљено 30. 09. 2016. 
  73. ^ „VSS/SourceSafe Jobs, Average Salary for Microsoft Visual SourceSafe (VSS) Skills”. Itjobswatch.co.uk. Приступљено 30. 09. 2016. 
  74. ^ Pettersen, Tim (20 December 2014).
  75. ^ Hamano, J, C. (18 December 2014).
  76. ^ "CVE-2015-7545". 15 December 2015.
  77. ^ "Git 2.6.1". 29 September 2015.
  78. ^ а б в Blake Burkhart; et al. (5 October 2015).

Литература уреди

Преузето из „https://sr.wikipedia.org/w/index.php?title=Git&oldid=27542813”