Git (софтуер)

Git
	Git
	Сесия на командния ред, показваща създаване на хранилище, добавяне на файл и отдалечена синхронизация.
Информация
Автор	Линус Торвалдс
Разработчик	Джунио Хамано и др.
Начална версия	7 април 2005 г.
Последна версия	2.47.1; 25 ноември 2024 г.
Програмен език	C, Perl, Tcl, Python, C++
Операционна система	POSIX (GNU/Linux, macOS, Solaris, AIX), Microsoft Windows
Език на интерфейса	английски, български, каталонски, френски, индонезийски, шведски, турски, украински, виетнамски, опростен китайски, тайвански мандарин
Статус	активен
Вид софтуер	децентрализирана система за контрол на версиите на файлове
Лиценз	GNU General Public License
Уебсайт	git-scm.com
	Git в Общомедия

Git (произнася се „гит“) е децентрализирана система за контрол на версиите на файлове. Създадена е от Линус Торвалдс за управление на разработката на Linux. Поради нуждата да се контролира огромната база от код на Linux ядрото, основна цел при разработката на Git е била бързината. Координатор на разработката на Git е Джунио Хамано.

Всяка локална Git директория е хранилище с пълна история и възможности за следене на версиите. Това прави Git независим от мрежови връзки към централен сървър.

Git е свободен софтуер и се разпространява под GPL лиценз версия 2. Текстовият интерфейс на програмата е преведен на български.

История

Разработката на Git започва след като много от разработчиците на Линукс ядрото преустановяват използването на BitKeeper – тогавашният избор за система за контрол на версиите.

В търсенето си на алтернатива на BitKeeper, Торвалдс не намира свободна система, която да посреща изискванията му. Едно от главните му изисквания е бързодействието. Той дава пример как за да промени малко парче от код, на съществуващ проект, му отнема тридесет секунди. Това обаче е много за проекти с мащаба на Линукс ядрото, където подобни промени се случват от порядъка на 250 пъти.^[1] Други водещи критерии в избора му са:

CVS е пример как да не се правят нещата.
Децентрализиране контрола на версиите, по пример на BitKeeper.
Твърди мерки против грешки, както случайни, така и преднамерени.

По онова време само Monotone отговаря на изискванията му, но като се вземе предвид желанието на Торвалдс за по-добра производителност и тази система за контрол на версиите отпада. Той решава непосредствено след завършване на 2.6.12-rc2 ядрото да се отдаде изцяло на разработването на Git.

Изборът на името Git не е много ясен и има различни версии защо точно така Торвалдс е избрал да нарече проекта си. В жаргон на Английски git означава „неприятен човек“. Линус се шегува, че понеже е егоцентричен обича да кръщава проектите на себе си.^[2]

Торвалдс преотстъпва разработването на 26 юли 2005 на Джунио Хамано.

Дизайн

Гит до голяма степен е вдъхновен от BitKeeper и Monotone. Дизайнът е силно повлиян от опита на Торвалдс с файлови системи.^[3] Първоначалният му замисъл е да създаде платформа от ниско ниво за система за контрол на версиите и върху нея да бъдат създавани инструменти като Cogito и StGIT. В процесът на разработка обаче гит се превръща в самостоятелна система за контрол на версиите, която може да се използва директно.

Структури от данни

Гит използва два вида структури от данни:

Индекс (познат още като stage или cache), който следи промените между работната директория и предстоящата версия за предаване. Структурата е променлива.
База от обекти, които не могат да бъдат променяни. Към нея може само да се прибавят нови обекти и те биват четири вида:

Обект от тип blob, е съдържанието на файл. Обектът не се ангажира да пази метадата подобно на файловете.
Обект от тип tree, е еквивалентът на директория. Съдържа списък от имена на файлове и съответстващия му blob или друг tree обект описващ под-директория. Представлява моментното състояние на проекта.
Обект от тип commit (конкретна единица промяна), свързва tree обекти за да формира история на промените. Съдържа името на tree обекта, време на промяната, съобщение, описващо промяната, и имената на предишните обекти от тип commit, ако има такива.
Обект от тип tag, е контейнер за препратки към друг обект и може да съдържа допълнителна метаданна, свързана с друг обект.

Индексът служи като свръзка между базата с обекти и работната директория.

Всеки обект е уникално идентифицира със SHA-1 хеш на съдържанието му. Гит изчислява този хеш и го използва за име на обекта. Обектът се поставя в директорията, отговаряща на първите два символа на хеша. Остатъкът се използва за име на самия обект.

Гит съдържа всяка версия на файл като уникален обект от тип blob. Връзката между тези обекти може да бъде като се разглеждат tree и commit обектите. Нововъведените обекти се съхраняват компресирани, но тъй като се компресират всеки сам по себе си, това може да доведе до използване на много дисково пространство. За да се избегне това, обектите могат да се комбинират в пакети, които използват делта компресия.

Характеристики

Силно застъпена поддръжка на нелинейно разработване: Гит поддържа бързо разклоняване и сливане, както и необходимите инструменти за визуализиране и навигация в нелинейна история на промените. Разклоненията в гит са просто връзка до един commit. Този commit от своя страна има родител и може да бъде пресъздадена цялата структура.
Разпределено разработване: Подобно на други системи за контрол на версиите, гит дава на всеки разработчик локално копие на цялата история на проекта. Промените се копират от едно такова хранилище до друго и се третират като допълнителни разклонения, които могат да се сливат също както локалните разклонения.
Съвместимост със съществуващи протоколи: Хранилищата могат да бъдат създавани чрез HTTP, FTP, rsync, SSH или гит протокол. Гит може също така да емулира CVS сървър. Subversion може да се използва директно благодарение на git-svn командата.
Ефикасно справяне с големи проекти: По думите на Торвалдс гит е много бърз, без значение от мащаба^[4]. Тестове направени от Mozilla показват, че гит е няколко порядъка по-бърз в сравнение с някои системи за контрол на версиите.^[5]
Криптографска проверка на историята: Историята в Гит се записва по такъв начин, че идентификацията на определена версия зависи от всички предишни версии. Структурата наподобява хеширано дърво, но с допълнителна информация към разклоненията и листата.^[6]

Главни действия

Създаване и участие в проекти

init: Използва се за първоначално инициализиране на проект. Проектът се създава в текущата директория.
clone: Използва се за сваляне на съществуващ проект.

Основни

add: Използва се за първоначално добавяне на файлове към проекта или тяхното променяне.
status: Използва се за проверка на състоянието на проекта и файловете в текущото разклонение.
diff: Използва се за визуализиране на промените във файловете, които не са записани в индекса (unstaged).
commit: Използва се за записване на промените в дървовидната структура commit.
reset: Използва се за изваждане на файлове от индекса (unstaging) с цел да не влязат в следващия commit.
rm: Използва се за перманентно премахване на файл от индекса.
stash: Използва се за запазване моментното състояние на индекса с цел да се довърши по-късно и връща състоянието на последния commit.

Разклоняване и сливане

branch: Изброява, създава и управлява разклоненията на проекта.
checkout: Сменя временният контекст(branch), в който се работи
merge: Използва се за сливане на разклонения.
log: Използва се за проследяване историята на промените в проекта.
tag: Използва се за отбелязване на commit, който трябва да се отличава от другите.

Споделяне и актуализиране

fetch: Използва се за сваляне на нова разклонения от отдалечени хранилища
pull: Използва се за сваляне на промените от отдалечено хранилище и се прави опит да се слеят заедно с локалното
push: Качва промените на отдалечено хранилище.
remote: Изброява, добавя и премахва псевдоними на отдалечени хранилища.

Външни препратки

Източници

↑ Torvalds, Linus. Re: Kernel SCM saga. // 7 април 2005. „So I'm writing some scripts to try to track things a whole lot faster.“
↑ GitFaq: Why the 'git' name? // Git.or.cz. Посетен на 14 юли 2012.„I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'“
↑ Torvalds, Linus. Re: more git updates... // 10 април 2005.
↑ Torvalds, Linus. Re: VCS comparison table // 19 октомври 2006.
↑ Dreier, Roland. Oh what a relief it is // 13 ноември 2006., observing that „git log“ is 100x faster than „svn log“ because the latter has to contact a remote server.
↑ Trust // Git Concepts. Git User's Manual, 18 октомври 2006.

[1] Torvalds, Linus. Re: Kernel SCM saga. // 7 април 2005. „So I'm writing some scripts to try to track things a whole lot faster.“

[whythegitname-2] GitFaq: Why the 'git' name? // Git.or.cz. Посетен на 14 юли 2012.„I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'Git'“

[3] Torvalds, Linus. Re: more git updates... // 10 април 2005.

[4] Torvalds, Linus. Re: VCS comparison table // 19 октомври 2006.

[5] Dreier, Roland. Oh what a relief it is // 13 ноември 2006., observing that „git log“ is 100x faster than „svn log“ because the latter has to contact a remote server.

[6] Trust // Git Concepts. Git User's Manual, 18 октомври 2006.

[1]

[2]

[3]

[4]

[5]

[6]