Завдяки механізму замінників, репозиторій може успадкувати частину своєї бази даних обʼєктів від іншої бази даних об’єктів, яка називається «замінником».

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

Обʼєкт без типу, наприклад, вміст файлу.

«Гілка» — це лінія розробки. Найновіший коміт в гілці називається верхівкою цієї гілки. Верхівка гілки посилається на вказівник, який переміщується вперед у міру продовження розробки на гілці. Одинрепозиторій Git може відстежувати довільну кількість гілок, але ваше робоче дерево повʼязане лише з однією з них («поточною» або «вибраною» гілкою), а вказівник HEAD вказує на цю гілку.

Замінено на: індекс.

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

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

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

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

Робоче дерево вважається чистим, якщо воно відповідає ревізії, на яку посилається поточний головний вузол. Див. також «брудне».

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

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

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

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

Об’єкт коміту або об’єкт, який можна рекурсивно перетворити на посилання на об’єкт коміту. До «комітоподібних» належать: об’єкт коміту, об’єкт тегу, що вказує на об’єкт коміту, об’єкт тегу, що вказує на об’єкт тегу, який вказує на об’єкт коміту, тощо.

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

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

Недосяжний об’єкт, який не є досяжним навіть з інших недосяжних об’єктів; на підвішений об’єкт немає жодних посилань з жодного посилання або об’єкта у репозиторії.

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

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

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

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

«Зловмисне злиття» — це злиття, яке вносить зміни, яких немає у жодного з пращурів.

«Перехід вперед» — це особливий вид операції злиття, коли у вас є ревізія> і ви «зливаєте» зміни іншої <<def_branch,гілки, яка є нащадком вашої гілки. У такому випадку ви не створюєте новий коміт><<def_merge,злиття, а просто оновлюєте свою гілку, щоб вона вказувала на ту саму ревізію, що й гілка, яку ви зливаєте. Це часто трапляється на гілці віддаленого відстеження віддаленого репозиторію.

Отримання гілки означає одержання посилання на вершину гілки з віддаленого репозиторію, визначення, яких об’єктів бракує в локальній базі даних об’єктів, та їхнє завантаження. Див. також git-fetch[1].

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

Синонім до репозиторій.

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

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

У контексті Git, синонім імені обʼєкта.

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

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

Синонім до head.

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

Збірка файлів зі статистичною інформацією, вміст яких зберігається у вигляді об’єктів. Індекс — це збережена версія вашого робочого дерева. Насправді він може містити також другу і навіть третю версії робочого дерева, які використовуються під час злиття.

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

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

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

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

Зберігає набір «об’єктів», причому кожен окремий об’єкт ідентифікується за допомогою імені об’єкта. Зазвичай об’єкти зберігаються в теці $GIT_DIR/objects/.

Синоніми імені обʼєкта.

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

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

Злиття більше ніж двох гілок.

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

Стандартний висхідний репозиторій. Більшість проєктів мають принаймні один висхідний проєкт, за яким вони стежать. Як правило, для цього використовується «origin». Нові оновлення з висхідного проєкту будуть завантажуватися у гілки віддаленого відстеження з іменами origin/назва-гілки-висхідного-проєкту, які можна переглянути за допомогою команди git branch -r.

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

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

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

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

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

Операція рекурсивного розгортання об’єкта тегу.

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

Мила назва для core Git. Цей термін можна порівняти з прокладанням труб (трубопроводом), зʼєднанням одних частин з іншими, що відбувається поза полем зору користувача.

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

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

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

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

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

Всі пращури даного коміту вважаються «доступними» з цього коміту. У більш загальному сенсі, один обʼєкт> є доступним з іншого, якщо ми можемо дістатися до нього з іншого за допомогою <<def_chain,ланцюжка, який слідує за тегами до будь-чого, що вони позначають, за коммітами до їхніх батьків або дерев, та за деревами до дерев або блобами, які вони містять.

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

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

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

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

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

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

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

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

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

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

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

Інструмент управління вихідним кодом, теж саме що й управління версіями, система контролю версій.

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

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

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

Обʼєкт який використовується для тимчасового зберігання вмісту робочої ( <<def_dirty,dirty>) теки та індексу для подальшого використання.

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

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

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

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

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

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

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

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

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

Обʼєкт tree або обʼєкт, який можна рекурсивно розгорнути в обʼєкт tree. Розгортання обʼєкта коміт повертає обʼєкт дерево, що відповідає верхній теці ревізії. Наступні обʼєкти є деревоподібними: commit-подібні, обʼєкт дерево, об’єкт tag, що вказує на обʼєкт дерева, обʼєкт tag, що вказує на обʼєкт tag, що вказує на обʼєкт дерева тощо.

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

Індекс, що містить необʼєднані елементи index.

Обʼєкт, який не є досяжним з гілки, тегу або будь-якого іншого посилання.

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

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

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