5.1 Git инструменти - Избор на къмити

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

Git е достатъчно гъвкав да определи кой къмит имате предвид, ако укажете първите няколко символа от хеша, стига да подадете поне 4-символен, недвусмислен стринг. Това значи, че в базата данни с обектите няма друг такъв, който да започва със същия префикс.

Например, за да изследвате специфичен къмит, в който знаете че сте добавили дадена функционалност, бихте могли първо да изпълните git log, за да го намерите:

В този случай, нека кажем, че се интересувате от къмита, чийто хеш започва с 1c002dd…​. Можете да инспектирате къмита с всеки от следните варианти на git show:

Git може да установи късите, уникални абревиатури на вашите SHA-1 стойности. Ако подадете опцията --abbrev-commit към git log, ще бъдат отпечатани съкратените версии; по подразбиране Git използва седем символа:

В общи линии, 8 до 10 символа са повече от достатъчни за гарантирана уникалност в рамките на един проект. Например, към февруари 2019, Linux ядрото (доста мащабен проект) има над 875 хиляди къмита и почти 7 милиона обекта, като не съществуват два такива с повтарящи се първи 12 символа в своя SHA-1 хеш.

Един прост начин да се обърнете към специфичен къмит, ако той е на върха в даден клон, е директно да използвате името на клона във всяка Git команда, която очаква референция към къмит. Например, ако искате да изследвате последния къмит в клон, следните две команди са еквивалентни, ако името на клона е topic1 и клонът сочи към къмита с хеш ca82a6d…​:

Ако искате да видите към кой специфичен SHA-1 сочи клона или да разберете как се представят тези примери по отношение на SHA-1 хешовете, можете да ползвате plumbing инструмент на Git наречен rev-parse. Можете да видите Git на ниско ниво за повече информация за plumbing инструментите; в общи линии, rev-parse се използва за операции на по-ниско ниво и не е предназначен за ежедневни дейности. Обаче, понякога той може да е полезен, ако искате да знаете какво се случва зад кулисите. Ето как можете да стартирате rev-parse във вашия клон.

Едно от нещата, които Git прави на заден план докато вие работите, е да пази т. нар. “reflog” — дневник на това къде са били вашите HEAD и branch референции за последните няколко месеца.

Можете да го видите с командата git reflog:

Всеки път, когато върхът на клона се обнови по каква да е причина, Git съхранява тази информация за вас в тази временна история. Можете да я използвате за да се обръщате към по-стари къмити. Например, ако искате да видите петата предишна стойност на HEAD на вашето хранилище, можете да използвате референцията @{5}, която се вижда в историята:

Можете да ползвате същия синтаксис за да видите къде е бил клона преди определено време. Ако искате примерно да разбере в какво състояние е бил master клона вчера, можете да изпълните:

Това ще ви покаже къде е сочил върха на master клона вчера. Тази техника обаче работи само за данни, които все още са в reflog историята, така че не можете да я използвате за къмити по-стари от няколко месеца.

За да видите reflog информацията форматирана като git log изход, изпълнете git log -g:

Важно е да се подчертае, че reflog информацията е строго локална — това е дневник на действията, които само вие сте извършили във вашето хранилище. Референциите няма да са същите в копието на хранилището на някой друг. Също така, веднага след като сте клонирали хранилище, ще имате празна reflog история, понеже се подразбира, че все още не са правени никакви промени по него. Ако изпълните git show HEAD@{2.months.ago}, ще видите съответния къмит само ако сте клонирали проекта поне два месеца преди това — ако сте го клонирали по-късно, ще видите само първия ви локален къмит.

Другият основен начин да укажете къмит е през неговото родословие. Ако поставите символа ^ в края на референция към къмит, Git ще намери неговия родител. Да допуснем, че историята на проекта ви изглежда така:

Сега, можете да видите предишния къмит указвайки HEAD^, което означава “родителят на HEAD”:

Можете да въведете и число след ^ за да укажете кой родител искате – например, d921970^2 означава “вторият родител на d921970.” Този синтаксис е полезен само за merge къмити, които имат повече от един родител — първият родител на merge къмит е от клона, в който сте били по време на сливането (често това е master), докато вторият родител идва от клона, който е бил слят (примерно, topic):

Символът ~ (тилда) също се използва за референция на унаследявания. Той също указва първия родител, така че HEAD~ и HEAD^ са еквивалентни. Разликата идва, когато укажете и число. HEAD~2 означава “първият родител на първия родител,” или “дядото” — това трасира първите родители толкова пъти, колкото е указано с числото. Например, в историята от преди малко, HEAD~3 ще бъде:

Това може да се напише и като HEAD~, резултатът ще е същия:

Можете също да комбинирате тези символи — за да укажете втория родител на предишната референция (приемаме, че е бил merge къмит), използвайте HEAD~3^2 и т.н.

Видяхме как се указват единични къмити, нека да видим как може да реферираме и обхвати от къмити. Това е полезно при управлението на клонове — ако имате множество клонове код, можете да използвате подобен вид обръщения, за да отговорите на въпроси от рода на “Каква работа от този клон все още не съм слял в главния ми клон?”