Как Git може да ви помогне

Статията предполага, че вече сте запознати с git и основните функции, но за всеки случай нека освежим паметта ви:

Добавяне на файл към зоната на сцената:

Премахване на директория от индекса:

Замяна на последния фиксиране:

Създаване на нов клон от текущия ангажимент:

Създайте нов клон при фиксиране X и преминете към него:

Преместване на клон X за ангажиране Y:

Обединете текущия клон от посочения:

Пренастройте текущия клон за фиксиране:

Отхвърляне на промените в индекса:

Връщане на промените в работната директория:

Пренастройте ВСИЧКИ клонове!

(Използвайте git && не използвайте клонове) == изобщо не използвайте git. Когато работите с клонове, git ви позволява да правите страхотни неща.

Например сте работили върху набора от функции stringUtils, след това сте преминали към поправяне на грешки и сте направили няколко фиксации и сега историята на вашите фикси изглежда така:

Докато поправяте грешки, получавате идеята, че би било чудесно да използвате функция, която сте ангажирали с C2, като в същото време не се нуждаете от промени в C3.

Използваме cherry-pick - прилагане на промени от всеки ангажимент към текущия ангажимент:

След успешното отстраняване на грешката, вие правите нов ангажимент и след това обединявате клоните:

Имайте предвид, че git не прилага повторно C2 - само C4-C6.

Хрумва ви, че ангажиментът C6 прави твърде много промени и би било хубаво да го разделите на две. Преди това се отървете от клона stringUtils и преименувате bugFix на trunk.

git rebase -i

Интерактивното пребазиране не само ви позволява да разделите един ангажимент на няколко, но също така:

„Свиване“ ангажименти (скуош и поправяне);
редактирайте описанието на ангажимента (преформулирайте);
пренареждане на ангажименти;
изпълнява команди или скриптове на черупки между операции по сливане.

Например историята на фиксирането ви изглежда така:

Пребазирате C4 на C0:

Позволете ми да ви напомня, че ако възникне конфликт по време на пребазирането, след разрешаването му трябва да изпълните:

След приключване на пребазирането историята ви ще изглежда така:

Git предлага удобен инструмент за отстраняване на грешки - bisect.

Да предположим, че сте направили поредица от ангажименти и сега историята ви изглежда така:

В сегашното си състояние приложението се срива и не знаете кой коммит се е объркал. Използвайки бисект, лесно можете да разберете кой е виновен и какво да правите.

След това git ще ви каже колко фиксации все още има за проверка и преместване на HEAD към средния фиксатор: bisect използва двоичен алгоритъм за търсене. Казваме на git дали грешката се възпроизвежда в текущия фиксация или не, със съответните лоши/добри команди и чрез log2N стъпки (в най-лошия случай) намираме първия „грешен“ фиксиране.

За да завършите състоянието на търсене и да се върнете в първоначалната позиция HEAD, се обадете:

Откъсната глава

След като изпълним командата:

ще бъдем на предишния коммит bf61378. HEAD сега сочи директно към самия ангажимент, а не към клона: HEAD -> bf61378:

По същество ние сме вътре анонимен клон: ако направим няколко фиксации, тогава историята ще изглежда така:

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

За да запазите и приложите вашите промени, направени в този анонимен клон, трябва просто да създадете нов клон и да обедините/пребазирате според нуждите:

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

Възстановяване на данни

Всичко, което git е виждал поне веднъж, може да бъде възстановено. Нека разгледаме няколко типични ситуации на загуба и възстановяване на данни.

Възстановяване на изгубени ангажименти

И така, нека си представим: вие сте в главния клон и сте сигурни, че последните две фиксирания не са необходими и хакнете от рамото:

Върнахте се две ангажименти назад и всичко изглежда така, както сте искали - сякаш тези две комити никога не са съществували:

Но, както понякога се случва, минават пет минути и изведнъж разбирате, че сте допуснали ужасна грешка и наскоро изтрихте кода. наистина е необходимо. В този случай можете да използвате:

Git проследява всички промени, които се случват с HEAD - фиксирания, проверки, обединения, пребази и т.н. - всички записани в релог. Изпълнявайки тази команда, ще видите солиден списък на всички операции, които по някакъв начин са променили състоянието HEAD и, следователно, SHA-1 на загубените им ангажименти:

Тогава знаете какво да правите.

Не? Добре, предлагам:

Възстановяване на изгубени ангажименти (ниво 2)

За да усложни нещата, какво ще стане, ако изтриете директорията .gitlogs и сега пренаписването е безполезно? На помощ идва командата fsck:

Сред отпечатаните n реда ще видите:

Е, сега знаете какво да правите, да?

Възстановяване на данни, които не са включени в коммита

По-вероятна, но не по-малко трагична ситуация: индексирахте няколко нови файла и след това извършихте нулиране, тъй като те не бяха необходими, и след това внезапно са били необходими? Командата fsck също ще помогне тук:

Вашите файлове ще се появят в директорията .gitlost-foundother. Просто трябва да дефинирате какво е какво, защото вместо имена ще има SHA-1.

Възстановяване на неиндексирани файлове

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

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

Временно съхранение на промените

Типична ситуация - работите по нова функция и изведнъж ръководителят на екипа излиза при вас и казва: "% UserName%, пуснете всичко, НЯМА ВРЕМЕ ЗА ОБЯСНЕНИЕ, трябва да коригирате% BugName%." И вашият код е в некомпилиращо състояние. Какво да правя? Е ... Можете да ангажирате всичко в някакъв нов клон, след това да се върнете тук, да го завършите до приемливо състояние, да направите commit -amend и да обедините/rebase. И можете да улесните живота си с:

Командата за скриване скрива всички промени, направени след последния фиксиране. Можете да превключите към различен клон, да поправите грешката, да се върнете тук и да изпълните:

Всички ваши промени ще се прехвърлят към текущото състояние на работната директория. Чрез добавяне на опцията -index, вие също ще върнете промените в индекса (резултатите от командите add и rm).

Прилагането на запазени промени е същността на сливането, така че не се изненадвайте, ако трябва да разрешите конфликт.

С скривалището можете да съхранявате множество състояния в стека. Командата stash apply по подразбиране прилага последното запазено състояние; прилагането на конкретно състояние ще изглежда така (преди това, нека разгледаме всички налични запазени състояния):

Преди да въведете промените, съвсем логично е да ги разгледате:

Резултатът ще бъде подобен на изхода на командата git diff -v.

Можете да изчистите стека със скрито скриване и да изтриете конкретен със скрито скривалище stash @.

Отмяна на промените

Има две команди за нулиране и връщане за това. Командата за нулиране се използва, ако промените, които сте направили след последния фиксиране, не са необходими.

Командата за нулиране с опцията -merge ще отмени промените в сливането. Например, направихте някои промени във файл A и след това изтеглихте, за да извлечете промените за файл B. Не харесвате текущото състояние на файл B и искате да върнете промените. Извършването на git reset --hard ще го върне в предишното му състояние, както и отмените промените, които сте направили във файл A, докато правите git reset --merge ще се върне в предишното си състояние само файл Б.

Командата за връщане е полезна, ако искате да върнете промените, направени от някакъв ангажимент, и да създадете нов ангажимент - да речем, след това да натиснете и други разработчици също да се "върнат" в предишното състояние.

Така че нулирайте отменя фиксирайте, сякаш не е съществувало (става висящо ангажиране), върнете X създава нов ангажимент идентичен с ангажимент X.

Полезни съвети

Преминете към предишния клон с „плащане -“: