7.1 Інструменти Git - Вибір ревізій

Ви безсумнівно можете послатись на будь-який один коміт за допомогою його повного 40-символьного хеша SHA-1, проте існують більш зручні для людей методи послатись на коміт. Ця секція перелічує різноманітні способи, за допомогою яких ви можете звернутися до будь-якого коміту.

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

Наприклад, щоб переглянути окремий коміт, що, як ви знаєте, додав певний функціонал, ви можете спочатку виконати команду git log та знайти цей коміт:

У цьому випадку, скажімо, вас цікавить коміт, що його хеш починається з 1c002dd.... Ви можете дослідити цей коміт будь-якою з таких варіацій git show (якщо коротші версії однозначні):

Git може визначити унікальне скорочення для ваших значень SHA-1. Якщо додати --abbrev-commit до команди git log, вивід буде використовувати коротші значення, проте збереже їх унікальними. З цією опцією Git видає по сім символів, проте може використати й більше, якщо це необхідно для того, щоб SHA-1 був однозначним:

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

Наприклад, ядро Linux на жовтень 2017 (що є доволі великим проектом) містить більш ніж 7000000 комітів та майже шість мільйонів об’єктів, не має двох об’єктів, у яких перші 11 символів SHA-1 сум збігалися б.

Існує зручний спосіб послатися на коміт, якщо існує гілка, що на нього вказує — у цьому випадку достатньо просто використати назву гілки замість коміту в будь-якій команді Git, що очікує посилання на коміт. Наприклад, якщо ви бажаєте переглянути останній об’єкт-коміт на гілці, наступні команди рівнозначні, якщо гілка topic1 вказує на коміт ca82a6d...:

Якщо ви бажаєте побачити, на який саме SHA-1 вказує гілка, або якщо ви хочете побачити, з яким саме SHA-1 працює будь-який з цих прикладів, ви можете використати внутрішню команду Git під назвою rev-parse. Ви можете переглянути Git зсередини для докладнішого опису внутрішніх інструментів. Взагалі-то rev-parse існує для операцій низького рівня, та не створений для використання в повсякденних операціях. Втім, він може бути іноді корисним, якщо вам треба побачити, що відбувається насправді. У даному випадку ви можете використати rev-parse на своїй гілці.

Одна з речей, які Git робить у фоні доки ви собі працюєте — він зберігає “reflog” — журнал того, де був ваш HEAD та гілкових посилань за останні декілька місяців.

Ви можете продивитись свій журнал посилань за допомогою git reflog:

Щоразу, коли вершина вашої гілки оновлюються за будь-якої причини, Git зберігає цю інформацію для вас у цій тимчасовій історії. За допомогою даних журнала посилань ви можете посилатися на старші коміти. Наприклад, якщо ви бажаєте побачити п’яте попереднє значення HEAD вашого сховища, ви можете використати посилання @{5}, яке ви бачите у виводі git reflog:

Ви також можете використовувати цей синтаксис, щоб побачити де була гілка якийсь заданий час тому. Наприклад, щоб дізнатись, де була ваша гілка master вчора, ви можете набрати

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

Щоб побачити інформацію журналу посилань у форматі, який видає git log, ви можете просто виконати git log -g:

Важливо зазначити, що вся інформація журналу посилань виключно локальна — це журнал лише того, що ви робили у своєму сховищі. Посилання будуть іншими на іншій копії сховища. Та відразу після клонування сховища, у вас буде порожній журнал посилань, адже жодної діяльності у вашому сховищі ще не було. Виконання git show HEAD@{2.months.ago} покаже відповідний коміт тільки якщо ви зробили клон проекту щонайменше два місяці тому — якщо ви зробили клон бодай на день пізніше, то ви побачите лише свій перший локальний коміт.

Іншим розповсюдженим способом задавати коміт — за допомогою його пращурів. Якщо ви поставите ^ (циркумфлекс) наприкінці посилання, Git вирішить, що воно означає батька цього коміту. Припустімо, що ви дивитесь на історію свого проекту:

Тоді ви можете побачити попередній коміт за допомогою HEAD^, що означає “батько HEAD”:

Ви також можете задати число після ^ — наприклад, d921970^2 означає “другий батько коміту d921970.” Цей синтаксис корисний тільки для комітів злиття, які мають більш ніж одного батька. Перший батько — це гілка, на якій ви були при злитті, а другий — це коміт гілки, яку ви зливали:

Другою головною операцією для вибору пращурів є ~ (тильда). Вона також вказує на першого батька, отже HEAD~ та HEAD^ рівнозначні. Різниця з’являється, коли ви додаєте число. HEAD~2 означає “перший батько першого батька,” або “дідусь” — вона переходить вздовж перших батьків задану кількість разів. Наприклад, у наведеній вище історії, HEAD~3 буде

Це також може бути записано як HEAD^^^, що також є першим батьком першого батька першого батька:

Ви також можете поєднувати ці синтаксиси - ви можете отримати другого батька попереднього посилання (якщо це був коміт злиття) за допомогою HEAD~3^2 тощо.

Тепер, коли ви вже знаєте, як задавати індивідуальні коміти, розгляньмо як задавати інтервали комітів. Це особливо корисно для керування гілками - якщо у вас багато гілок, ви можете використовувати специфікації інтервалів для відповіді на запитання на кшталт “Що зроблено у цій гілці, проте досі не злито до головної гілки?”