Через механізм альтернатив, repository може успадковувати частину своєї object database від іншої об’єктної бази даних, яка називається "альтернативною".

Голий репозиторій зазвичай є відповідним чином названим directory із суфіксом .git, який не має локально витягнутої копії жодного з файлів під контролем версій. Тобто, всі адміністративні та керуючі файли Git, які зазвичай присутні в прихованому підкаталозі .git, безпосередньо присутні в каталозі repository.git, і жодні інші файли не присутні та не витягнуті. Зазвичай видавці публічних репозиторіїв роблять доступними голі репозиторії.

Нетипізований object, наприклад, вміст файлу.

«Гілка» – це лінія розробки. Найновіший commit на гілці називається верхівкою цієї гілки. Верхівка гілки називається referenced гілкою head, яка рухається вперед, коли на ній виконується додаткова розробка. Одна гілка Git repository може відстежувати довільну кількість гілок, але ваша working tree пов’язана лише з однією з них («поточною» або «використаною» гілкою), а HEAD вказує на цю гілку.

Застаріло для: index.

Список об’єктів, де кожен object у списку містить посилання на свого наступника (наприклад, наступником commit може бути один з його parents).

BitKeeper/cvsps використовуються для визначення "commit". Оскільки Git не зберігає зміни, а зберігає стани, використання терміна "набори змін" з Git насправді не має сенсу.

Дія оновлення всього або частини working tree за допомогою об’єкта tree або blob з бази даних object, та оновлення index та HEAD, якщо все робоче дерево було спрямовано на нову branch.

На жаргоні SCM «вибір cherry pick» означає вибір підмножини змін із серії змін (зазвичай комітів) та запис їх як нової серії змін поверх іншої кодової бази. У Git це виконується командою «git cherry-pick», щоб витягти зміну, внесену існуючим commit, та записати її на основі кінчика поточної branch як новий коміт.

Дерево working_tree вважається чистим, якщо воно відповідає revision, на яке посилається поточне head. Див. також "dirty".

Як іменник: Окремий момент в історії Git; вся історія проекту представлена як набір взаємопов’язаних комітів. Слово "commit" часто використовується Git там, де інші системи контролю версій використовують слова "revision" або "version". Також використовується як скорочене позначення для commit object.

Синонім структури DAG, утвореної комітами в базі даних об’єктів, referenced – підказками гілок, використовуючи chain пов’язаних комітів. Ця структура є остаточним графом комітів. Граф можна представити іншими способами, наприклад, файлом "commit-graph".

Файл "commit-graph" (зазвичай через дефіс) є додатковим представленням commit graph, яке пришвидшує прогулянки графом комітів. Файл "commit-graph" зберігається або в каталозі .git/objects/info, або в каталозі info альтернативної бази даних об’єктів.

Об’єкт object, що містить інформацію про певний revision, такий як parents, комітер, автор, дата та об’єкт tree, що відповідає верхньому directory збереженої ревізії.

Об’єкт commit або object, який можна рекурсивно dereferenced перевести в об’єкт commit. Наступні об’єкти є аналогами commit: об’єкт commit, об’єкт tag, що вказує на об’єкт commit, об’єкт tag, що вказує на об’єкт tag, що вказує на об’єкт commit тощо.

Фундаментальні структури даних та утиліти Git. Надає доступ лише до обмежених інструментів керування вихідним кодом.

Орієнтований ациклічний граф. Об’єкти commit утворюють орієнтований ациклічний граф, оскільки вони мають батьків (орієнтовані), а граф об’єктів commit є ациклічним (немає chain, який починається та закінчується тим самим object).

Об’єкт недосяжний, який не є досяжним навіть з інших недосяжних об’єктів; висячий об’єкт не має посилань на нього з жодного посилання або object в repository.

Посилання на символічне посилання: дія доступу до посилання, на яке вказує символічне посилання. Рекурсивне розіменування включає повторення вищезгаданого процесу для результуючого посилання, доки не буде знайдено несимволічне посилання.

Зазвичай, HEAD зберігає назву branch, а команди, що працюють з історією, яку представляє HEAD, працюють з історією, що веде до вершини гілки, на яку вказує HEAD. Однак, Git також дозволяє вам check out довільну commit, яка не обов’язково є вершиною якоїсь конкретної гілки. HEAD у такому стані називається "відокремленим".

Список, який ви отримуєте за допомогою "ls" :-)

working tree називається "брудним", якщо воно містить модифікації, які не були committed внесені до поточної branch.

Злісне злиття — це merge, яке вносить зміни, що не відображаються в жодному parent.

Перемотування вперед — це особливий тип merge, де у вас є revision, і ви "зливаєте" зміни з іншої branch, які є нащадком вашої. У такому випадку ви не створюєте новий merge commit, а просто оновлюєте свою гілку, щоб вона вказувала на ту саму ревізію, що й гілка, яку ви зливаєте. Це часто трапляється на гілці remote-tracking віддаленого repository.

Отримання branch означає отримання head ref гілки з віддаленого repository, щоб знайти, які об’єкти відсутні в локальній object database, та отримати їх. Див. також git-fetch[1].

Лінус Торвальдс спочатку розробляв Git як файлову систему простору користувача, тобто інфраструктуру для зберігання файлів і каталогів. Це забезпечило ефективність і швидкість Git.

Синонім до repository (для архітекторів).

Звичайний файл .git у корені робочого дерева, який вказує на каталог, що є справжнім репозиторієм. Інструкції з правильного використання див. у git-worktree[1] або git-submodule[1]. Синтаксис див. у gitrepository-layout[5].

Графти дозволяють об’єднати дві інакше різні лінії розробки, записуючи фальшиву інформацію про походження для комітів. Таким чином, ви можете змусити Git вдавати, що набір parents commit відрізняється від того, що було записано під час створення коміту. Налаштовується через файл .git/info/grafts.

У контексті Git, синонім object name.

Посилання іменоване на commit наприкінці branch. Заголовки зберігаються у файлі в каталозі $GIT_DIR/refs/heads/, за винятком випадків використання упакованих посилань. (Див. git-pack-refs[1].)

Поточна branch. Детальніше: Ваше робоче дерево зазвичай походить від стану дерева, на яке посилається HEAD. HEAD – це посилання на один з heads у вашому репозиторії, за винятком випадків використання detached HEAD, у цьому випадку воно безпосередньо посилається на довільний коміт.

Синонім до head.

Під час звичайного виконання кількох команд Git викликаються додаткові скрипти, які дозволяють розробнику додавати функціональність або перевіряти. Зазвичай, перехоплювальні скрипти дозволяють попередньо перевірити команду та потенційно перервати її, а також дозволяють відправити повідомлення після завершення операції. Перехоплювальні скрипти знаходяться в каталозі $GIT_DIR/hooks/ та активуються простим видаленням суфікса .sample з назви файлу. У попередніх версіях Git їх потрібно було зробити виконуваними.

Колекція файлів зі статистичною інформацією, вміст яких зберігається як об’єкти. Індекс – це збережена версія вашого working tree. Правду кажучи, він також може містити другу, і навіть третю версію робочого дерева, які використовуються при merging.

Інформація щодо певного файлу, що зберігається в index. Запис індексу можна роз’єднати, якщо merge було розпочато, але ще не завершено (тобто, якщо індекс містить кілька версій цього файлу).

Розробка за замовчуванням branch. Щоразу, коли ви створюєте Git repository, створюється гілка з назвою "master", яка стає активною гілкою. У більшості випадків вона містить локальну розробку, хоча це виключно за домовленістю і не є обов’язковим.

Як дієслово: Перенести вміст іншої branch (можливо, із зовнішнього repository) до поточної гілки. У випадку, коли об’єднана гілка знаходиться з іншого репозиторію, це робиться спочатку шляхом fetching віддаленої гілки, а потім об’єднання результату з поточною гілкою. Ця комбінація операцій вибірки та злиття називається pull. Об’єднання виконується автоматичним процесом, який ідентифікує зміни, внесені з моменту розбіжності гілок, а потім застосовує всі ці зміни разом. У випадках, коли зміни конфліктують, для завершення об’єднання може знадобитися ручне втручання.

Одиниця сховища в Git. Вона однозначно ідентифікується SHA-1 її вмісту. Отже, об’єкт не можна змінити.

Зберігає набір "об’єктів", а окремий object ідентифікується за його object name. Об’єкти зазвичай знаходяться в $GIT_DIR/objects/.

Синонім до назва_об’єкта.

Унікальний ідентифікатор object. Ім’я об’єкта зазвичай представлено шістнадцятковим рядком із 40 символів. Також розмовно називається SHA-1.

Один з ідентифікаторів "commit", "tree", "tag" або "blob", що описує тип object.

Щоб виконати merge більше двох branches.

Акт переходу на гілку branch, яка ще не існує (тобто гілку unborn). Після такої операції спочатку створений коміт стає комітом без батьківського елемента, починаючи нову історію.

За замовчуванням розгортається <<def_repository,repository>>. Більшість проектів мають принаймні один розгортається проект, який вони відстежують. За замовчуванням для цієї мети використовується origin. Нові оновлення розгортаються будуть завантажуватися в <<def_remote_tracking_branch,remote-tracking branchs>> з назвою origin/name-of-upstream-branch, яку ви можете побачити за допомогою git branch -r.

Оновлювати та додавати файли лише до робочого каталогу, але не видаляти їх, подібно до того, як cp -R оновлює вміст у каталозі призначення. Це режим за замовчуванням у checkout під час отримання файлів з index або tree-ish. На противагу цьому, режим без накладання також видаляє відстежувані файли, яких немає у джерелі, подібно до rsync --delete.

Набір об’єктів, стиснутих в один файл (для економії місця або ефективної передачі).

Список ідентифікаторів та іншої інформації про об’єкти в pack, що допомагає в ефективному доступі до вмісту пакета.

Шаблон, який використовується для обмеження шляхів у командах Git.

Об’єкт commit містить (можливо, порожній) список логічних попередників у лінії розробки, тобто його батьків.

Дія рекурсивного виконання dereferencing об’єкта tag.

Термін pickaxe стосується опції процедур diffcore, які допомагають вибирати зміни, що додають або видаляють заданий текстовий рядок. За допомогою опції --pickaxe-all її можна використовувати для перегляду повного changeset, який додав або видалив, скажімо, певний рядок тексту. Див. git-diff[1].

Миле ім’я для core Git.

Миле ім’я для програм та пакетів програм, що залежать від core Git, що забезпечує високорівневий доступ до ядра Git. Порцелянові елементи надають більше інтерфейсу SCM, ніж plumbing.

Посилання, що є per-worktree, а не глобальними. Наразі це лише HEAD та будь-які посилання, що починаються з refs/bisect/, але пізніше можуть включати інші незвичайні посилання.

Посилання, яке має іншу семантику, ніж звичайні посилання. Ці посилання можна зчитувати за допомогою звичайних команд Git, але не можна записувати в них за допомогою команд, таких як git-update-ref[1].

Витягування branch означає виконання fetch та merge її. Див. також git-pull[1].

Надсилання branch означає отримання head ref гілки з віддаленого repository, з’ясування, чи є вона предком локального head ref гілки, і в цьому випадку поміщення всіх об’єктів, які є reachable з локального head ref та які відсутні у віддаленому репозиторії, до віддаленої object database та оновлення віддаленого head ref. Якщо віддалений head не є предком локального head, надсилання завершується невдачею.

Усі предки заданого commit називаються "досяжними" з цього коміту. У більш загальному випадку, один object є досяжним з іншого, якщо ми можемо досягти одного з іншого за допомогою chain, який йде після tags до будь-якого їхнього тегу, commits до їхніх батьківських об’єктів або дерев, та trees до дерев або blobs, які вони містять.

Бітові карти досяжності зберігають інформацію про reachability вибраного набору комітів у пакетному файлі або індексі мультипаків (MIDX) для пришвидшення пошуку об’єктів. Бітові карти зберігаються у файлі ".bitmap". Репозиторій може використовувати щонайбільше один файл бітових карт. Файл бітових карт може належати або до одного пакету, або до індексу мультипаків репозиторію (якщо він існує).

Щоб повторно застосувати серію змін з branch до іншої бази та скинути head цієї гілки до результату.

Ім’я, що вказує на ім’я об’єкта або інше посилання (останнє називається символічне посилання). Для зручності посилання іноді можна скорочувати, коли воно використовується як аргумент команди Git; див. gitrevisions[7] для отримання детальної інформації. Посилання зберігаються в репозиторії.

Reflog показує локальну «історію» посилання. Іншими словами, він може повідомити вам, якою була третя остання ревізія в this репозиторії та який був поточний стан у this репозиторії вчора о 21:14. Див. git-reflog[1] для отримання детальної інформації.

"Refspec" використовується fetch та push для опису відповідності між віддаленим ref та локальним посиланням. Див. git-fetch[1] або git-push[1] для отримання детальної інформації.

Об’єкт repository, який використовується для відстеження того самого проєкту, але знаходиться деінде. Щоб зв’язатися з віддаленими серверами, див. fetch або push.

Гілка ref, яка використовується для відстеження змін з іншого repository. Зазвичай вона виглядає як refs/remotes/foo/bar (що вказує на те, що вона відстежує гілку з назвою bar у віддаленому репозиторії з назвою foo) та відповідає правій частині налаштованого fetch refspec. Гілка з віддаленим відстеженням не повинна містити прямих модифікацій або локальних комітів.

Колекція refs разом з object базою даних, що містить усі об’єкти, які є reachable з посилань, можливо, супроводжувані метаданими з одного або кількох porcelains. Репозиторій може спільно використовувати базу даних об’єктів з іншими репозиторіями через механізм alternates.

Дія виправлення вручну того, що залишилося після невдалого автоматичного merge.

Синонім до commit (іменник).

Відкинути частину розробки, тобто призначити head попередньому revision.

Управління вихідним кодом (інструмент).

"Secure Hash Algorithm 1"; криптографічна хеш-функція. У контексті Git використовується як синонім object name.

Здебільшого синонім shallow repository, але ця фраза чіткіше вказує на те, що його було створено за допомогою команди git clone --depth=....

Неглибокий repository має неповну історію, деякі з commits якої parents знищені (іншими словами, Git має вдати, що ці коміти не мають батьківських комітів, навіть якщо вони записані в commit object). Це іноді корисно, коли вас цікавить лише недавня історія проекту, хоча реальна історія, записана в апстрімі, набагато більша. Неглибокий репозиторій створюється шляхом надання опції --depth для git-clone[1], а його історію пізніше можна поглибити за допомогою git-fetch[1].

Об’єкт object використовується для тимчасового зберігання вмісту робочого каталогу dirty та індексу для подальшого використання.

Об’єкт repository, що містить історію окремого проєкту всередині іншого репозиторію (останній називається superproject).

Об’єкт repository, який посилається на репозиторії інших проектів у своєму робочому дереві як submodules. Суперпроект знає про назви (але не містить копій) об’єктів комітів підмодулів, що містяться в ньому.

Символічне посилання: замість того, щоб містити сам ідентифікатор SHA-1, воно має формат ref: refs/some/thing, і під час посилання воно рекурсивно dereferences переходить до цього посилання. HEAD є яскравим прикладом символічного посилання. Символьні посилання маніпулюють командою git-symbolic-ref[1].

Об’єкт ref у просторі імен refs/tags/, який вказує на об’єкт довільного типу (зазвичай тег вказує або на tag, або на commit об’єкт). На відміну від head, тег не оновлюється командою commit. Тег Git не має нічого спільного з тегом Lisp (який у контексті Git називався б object type). Тег найчастіше використовується для позначення певної точки в походженні комітів chain.

Об’єкт object, що містить ref, що вказує на інший об’єкт, який може містити повідомлення, як і об’єкт commit. Він також може містити підпис (PGP), і в цьому випадку він називається "підписаним об’єктом тегу".

Звичайний Git branch, який використовується розробником для визначення концептуальної лінії розробки. Оскільки гілки дуже прості та недорогі, часто бажано мати кілька невеликих гілок, кожна з яких містить дуже чітко визначені концепції або невеликі інкрементальні, але пов’язані зміни.

Метадані ключ-значення. Трейлери необов’язково знаходяться в кінці повідомлення коміту. В інших спільнотах можуть називатися "футерами" або "тегами". Див. git-interpret-trailers[1].

Або working tree, або tree object разом із залежними об’єктами blob та tree (тобто збережене представлення робочого дерева).

Об’єкт object, що містить список імен файлів та режимів, а також посилання на пов’язані блоб-об’єкти та/або деревоподібні об’єкти. tree еквівалентний directory.

Об’єкт tree або object, який можна рекурсивно dereference перенести на об’єкт дерева. Розіменування об’єкта commit повертає об’єкт дерева, що відповідає верхньому directory об’єкта revision. Наступні об’єкти є деревоподібними: commit-подібний, об’єкт дерева, об’єкт tag, що вказує на об’єкт дерева, об’єкт tag, що вказує на об’єкт tag, що вказує на об’єкт дерева тощо.

HEAD може вказувати на branch, якої ще не існує і на якій ще немає жодного коміту, і така гілка називається ненародженою гілкою. Найтиповіший спосіб, яким користувачі стикаються з ненародженою гілкою, - це створення репозиторію заново без клонування з іншого місця. HEAD вказуватиме на «головну» (або «головну», залежно від вашої конфігурації) гілку, яка ще не народилася. Також деякі операції можуть перемістити вас на ненароджену гілку за допомогою їхнього параметра orphan.

Об’єкт index, що містить необ’єднані записи index.

Об’єкт object, який не є reachable з branch, tag або будь-якого іншого посилання.

Значення за замовчуванням branch, яке об’єднується з відповідною гілкою (або на яке перебазується відповідна гілка). Налаштовується через branch.<name>.remote та branch.<name>.merge. Якщо гілкою вище за течією A є origin/B, іноді ми кажемо, що "A відстежує origin/B".

Дерево фактично отриманих файлів. Робоче дерево зазвичай містить вміст дерева комітів HEAD, а також будь-які локальні зміни, які ви внесли, але ще не закомітили.

До репозиторію може бути прикріплено нуль (тобто голий репозиторій) або одне чи декілька робочих дерев. Одне «робоче дерево» складається з «робочого дерева» та метаданих репозиторію, більшість з яких є спільними для інших робочих дерев одного репозиторію, а деякі з них підтримуються окремо для кожного робочого дерева (наприклад, індекс, HEAD та псевдопосилання, такі як MERGE_HEAD, посилання для кожного робочого дерева та файл конфігурації для кожного робочого дерева).