Как 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 колекционера на боклук .

---