5.7 Git инструменти - Мистерията на командата Reset

Един по-лесен подход да мислите за reset и checkout е да гледате на Git като мениджър на съдържание за три различни дървета. Като казваме “дърво”, в действителност разбираме “колекция от файлове”, а не структурата от данни. Има няколко ситуации, където индексът на практика не работи като дърво, но за нашите цели е по-лесно да го възприемаме като такова.

Git като система управлява три дървета в нормалната си работа:

Основната работна последователност на Git е да записва snapshot-и на проекта ни в последователни серии, манипулирайки тези три дървета.

Нека онагледим процеса: да кажем, че отиваме в нова директория с един файл в нея. Ще наречем това v1 на файла и ще го маркираме в синьо. Сега изпълняваме git init, което ще създаде ново Git хранилище с HEAD референция, която сочи към все още несъществуващ клон (master все още не е създаден).

На този етап, единствено работната ни директория има някакво съдържание.

Сега ще искаме да индексираме този файл, така че използваме git add за да вземем съдържанието от работната област и да го копираме в индексната.

След това, изпълняваме git commit, което ще вземе съдържанието на индекса и ще го запише като перманентен snapshot, ще създаде къмит обект, който сочи към този snapshot и ще настрои нашия master клон да сочи към този къмит.

Ако сега изпълним git status няма да видим промени, защото трите ни дървета са идентични.

Сега правим промяна по файла и го къмитваме. Ще минем през същия процес, първо променяме файла в работната директория. Нека наречем това v2 на файла и да го маркираме в червено.

Когато изпълним git status в този момент, ще видим този файл в червено в секцията “Changes not staged for commit”, защото той сега се различава от копието си в индекса. След това изпълняваме git add и го индексираме.

В момента, git status, ще ни покаже файла в зелен цвят в секцията “Changes to be committed” защото индексът и HEAD се различават — тоест нашият очаквам следващ къмит е различен от последно съхранения. Последно, изпълняваме git commit за да финализираме новия къмит.

Сега git status няма да покаже разлики, защото трите дървета отново са еднакви.

Клонирането и превключването на клонове минават през подобен процес. Когато превключим към друг клон, HEAD се променя и сочи към референцията на този клон, индексът се попълва със snapshot-а на този къмит и след това съдържанието на индекса се копира в работната директория.

Командата`reset` придобива по-ясно значение, когато се разглежда в такъв контекст.

За целта на тези примери, нека кажем, че сме променили file.txt отново и сме го къмитнали за трети път. Така историята ни сега ще изглежда по този начин:

Нека минем през това какво точно прави reset, когато я изпълним. Тя директно манипулира тези три дървета по прост и предвидим начин. Извършват се три основни операции.

Дотук разгледахме reset в основната ѝ форма, но можете също така да ѝ посочите път, по който да работи. Ако укажете път, reset ще пропусне стъпка 1 и ще ограничи действието си до специфичен файл/файлове. В това всъщност има смисъл — HEAD е просто указател и вие не можете да сочите част от един къмит и част от друг. Но индексът и работната директория могат да бъдат частично обновени, така че reset преминава към стъпки 2 и 3.

Да допуснем, че сте изпълнили git reset file.txt. Тази форма (понеже не сте указали SHA-1 на къмит или клон, както и параметрите --soft или --hard) е съкратена версия на командата git reset --mixed HEAD file.txt, която:

Така практически командата просто копира file.txt от HEAD в индекса.

Ефективно това деиндексира файла. Ако погледнем диаграмата за тази команда и помислим какво прави git add, ще установим че те работят точно по обратен начин.

Това е причината, поради която изходът на git status ви съветва да направите това за да деиндексирате файл (вижте Изваждане на файл от индекса за подробности).

Можем също толкова лесно да кажем на Git да “не изтегля данните от HEAD” указвайки специфичен къмит, от който да извлечем файла вместо това. В такива случаи изпълняваме нещо като git reset eb43bf file.txt.

Това ще направи същото нещо, както ако бяхме върнали назад съдържанието на файла до версията v1 в работната директория, бяхме изпълнили git add върху него и след това го бяхме възстановили обратно отново във версия v3 (без действително да минаваме през всички тези стъпки). Ако сега изпълним git commit, тя ще запише промяна, която връща файла до версия v1, въпреки че тази версия никога не сме я имали отново в работната директория.

Интересно е да се отбележи и, че подобно на git add, reset също приема --patch аргумент за да деиндексира съдържание в hunk-by-hunk стил. Така можете селективно да деиндексирате или връщате съдържание.

Нека видим как да направим нещо интересно с тази нова функционалност — да обединяваме къмити (squashing).

Да кажем, че имате серия къмити със съобщения като “oops.”, “WIP” и “forgot this file”. Можете да използвате reset за да ги обедините на бърза ръка в един общ къмит, което ще ви спечели уважение в очите на колегите. Обединяване на къмити показва друг начин да направите това, но в този пример е по-лесно да използваме reset.

Да приемем, че имате проект, в който първият къмит има един файл, вторият добавя нов файл и модифицира първия, а третият къмит модифицира първия файл още един път. Вторият къмит е бил work in progress и искате да го обедините с някой друг.

Може да изпълните git reset --soft HEAD~2 за да преместите HEAD клона назад към по-стар къмит (най-скорошния, който искате да запазите):

След това просто изпълнете git commit отново:

Сега може да видите, че достъпната ви история, тази която ще публикувате, вече съдържа един къмит с file-a.txt v1 и след това втори, който е модифицирал file-a.txt до версия v3 и е добавил file-b.txt. Къмитът с версия v2 на файла вече е извън историята.

Накрая, може да се запитате каква е разликата между checkout и reset. Подобно на reset, checkout манипулира трите дървета и може да е различна в зависимост от това дали ѝ подавате път или не.

Надяваме се, че сега се чувствате по-удобно с командата reset, но въпреки това знаем, че тя предизвиква конфуз, когато я сравнявате с checkout и е твърде възможно да забравите всички правила и различни начини на изпълнението ѝ.

Ето кратка таблица с това коя команда кое от дърветата променя. Колоната “HEAD” съдържа “REF”, ако командата отляво премества референцията (клона), към който сочи HEAD и съдържа “HEAD” ако командата премества самия HEAD. Обърнете специално внимание на 'WD Safe?' (безопасна за работната директория) колоната — ако тя съдържа NO, помислете добре преди да я изпълните.