Направо към съдържанието

Git (софтуер)

от Уикипедия, свободната енциклопедия
Git
Информация
РазработчикЛинус Торвалдс, Джунио Хамано, и други
Последна версия2.11.0
Програмен езикC, Shell, Perl
Операционна системаPOSIX, Linux, Windows, BSD
Вид софтуерУправление на версии
ЛицензGPL
Уебсайтgit-scm.com
Git в Общомедия

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

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

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

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

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

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

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

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

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

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

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

[редактиране | редактиране на кода]

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

Цикъл на разработване на проект.
  1. Индекс (познат още като stage или cache), който следи промените между работната директория и предстоящата версия за предаване. Структурата е променлива.
  2. База от обекти, които не могат да бъдат променяни. Към нея може само да се прибавят нови обекти и те биват четири вида:
  • Обект от тип 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
Изброява, добавя и премахва псевдоними на отдалечени хранилища.
  1. Torvalds, Linus. Re: Kernel SCM saga. // 7 април 2005. „So I'm writing some scripts to try to track things a whole lot faster.“
  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.