6 Git грешки, които ще допуснете - и как да ги поправите

Голяма причина разработчиците да използват система за контрол на източници като Git е да избягват бедствия. Ако направите нещо толкова просто, колкото погрешно изтриете файл, или откриете, че промените, които сте направили в дузина файлове, са били неразумни, можете да отмените това, което сте направили, с малко неприятности.

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

Ето списък на няколко от по-големите Git Boo-Boos, заедно със съвети за отстъпване от тях и предотвратяване на някои от тях. Колкото по-надолу слизате в списъка, толкова по-големи стават бедствията.

Git грешка # 1: Забравихте да добавите промени към последния фиксиране

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

Без страх. Първо, ако имате нови промени, които да бъдат инсценирани, направете това. След това въведете, за git commit --amendда редактирате съобщението за фиксиране. След като приключите, натиснете Esc, след това въведете, за :xqда запазите и излезете от редактора. (Тази последна стъпка е тази, която често вълнува новодошлите в Git, които не винаги осъзнават, че вграденият редактор на Git е много собствено животно.)

Ако просто сменяте файлове и не е необходимо да изменяте съобщението за фиксиране, можете да използвате, за git commit --amend --no-editда добавите файловете и да пропуснете процеса на редактиране на съобщението.

Един от начините да избегнете този вид грешка е да промените начина, по който правите ангажименти в Git. Ако работите върху нещо, при което постоянно правите малки ангажименти, за да проследявате постепенни ревизии, направете ги в изхвърлен клон. Докато правите това, документирайте основните промени, които правите някъде - не чакайте, докато не се изправите пред git commitкомандния ред, за да запишете всичко. След това, когато достигнете основен етап, използвайте git merge --squashот клона си за изхвърляне, за да запишете резултатите в незавършен клон като единичен, чист фиксиране и използвайте бележките, които сте направили за съобщението за фиксиране.

Git грешка # 2: Извършихте промени в (локален) мастер

Друг често срещан глупак: Послушно сте извършили куп промени ... но по грешка в главния клон на вашето репо. Това, което наистина искате да направите, е да ги ангажирате към нов клон или към този devклон, който имате специално за нарушаване на промените.

Всичко не е загубено. Тази грешка може да бъде отстранена в три команди:

git клон нов клон

git reset HEAD ~ --hard

git checkout нов клон

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

Ако сте направили няколко фиксации, използвайте git reset HEAD~ --hard, където е броят на ангажиментите, които искате да извършите. Или можете да използвате git reset , където е хеш идентификаторът на целевия фиксиране, ако имате това удобно.

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

Git грешка # 3: Изхвърлихте файл или директория в кошчето

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

Първо, използвайте git logили вградения Git инструментариум на вашата IDE, за да намерите ID на хеш за фиксиране отпреди модифицирането на файла. След това използвайте, за git checkout hash_id -- /path/to/fileда проверите само този файл от въпросния коммит. Обърнете внимание, че пътят трябва да бъде спрямо корена на проекта. Това ще постави по-ранната версия на файла в подреждането на проекта.

Ако просто искате да се върнете n ангажименти, не ви е необходим хеш ID. Можете просто да издадете командата git checkout HEAD~ -- /path/to/file, където е броят на връщанията, които искате да извършите.

Ако искате да проверите цяла директория с файлове, използвайте формата на заместващи символи на Git за файлови пътища. Например въвеждането  git checkout HEAD~1 -- ./src/**ще ви върне един ангажимент и ще възстановите всичко в /srcдиректорията от корена на вашия проект.

Git грешка # 4: Случайно сте изтрили клон

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

Първо, използвайте, за git reflogда намерите последния ангажимент, направен към клона. След това използвайте ID на хеш, за да създадете нов клон:

git checkout -b restored-branch

Имайте предвид, че това ще изпържи бекона ви само ако въпросният клон вече е бил обединен. Ако принудително изтриете несвързан клон, имате още един начин да го намерите, при условие, че не сте изпълнявали git gcхранилището:

git fsck --full --no-reflogs --unreachable --lost-found

Това ще извади списък с всички хешове на фиксиране за обекти, които вече не са достъпни, включително изтрити клонове. Потърсете отдолу на списъка запис за „недостижим ангажимент“ и опитайте да възстановите този хеш ID в нов клон, за да видите дали е този, който сте изхвърлили. Ако не е, преминете към списъка до следващия и вижте какво можете да възстановите.

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

Git грешка # 5: Премахнахте отдалечения клон с git push

След като работех над локално копие на хранилище на GitHub и по погрешка натиснах главния си клон към отдалеченото копие с --forceопцията. В крайна сметка получих публично копие на репо, което по това време не беше в използваемо състояние. Големи опа.

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

git reset --hard /@{1}

Това ще нулира вашето копие на последната синхронизирана версия на . В моя случай клонът беше masterи отдалеченото репо беше origin, така че можех да използвам git reset --hard origin/[email protected]{1}.

След това използвайте, за git push -f да възстановите отдалеченото хранилище в предишното му състояние.

Един от начините да се предотврати това да се повтори е да се забрани натискането със сила. Можете да конфигурирате това на отдалеченото Git репо с тази команда:

git config --system receive.denyNonFastForwards true

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

Git грешка # 6: Извършихте лична информация на публичен репо

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

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

Добрата новина: Няколко безстрашни Git mavens създадоха инструмент, BFG Repo-Cleaner, специално с цел премахване на лоши данни от Git репозитории. BFG Repo-Cleaner ви позволява бързо да изпълнявате общи задачи при репо, като например да премахвате всички файлове, съответстващи на даден заместващ символ или съдържащи определени текстове. Можете дори да предадете файл, в който са изброени всички нежелани текстове.

BFG Repo-Cleaner е по същество автоматизация за многоетапен процес, използващ git filter-branch. Ако предпочитате да правите нещата на ръка, GitHub има подробно описание на процеса. Но инструментът BFG обхваща по-голямата част от често използваните случаи, много от които са включени в опциите на командния ред на инструмента. Освен това процесът е дълъг и сложен и е твърде лесно да си стреляш в крака някъде по пътя, ако го правиш на ръка.

Имайте предвид, че ако почиствате данни от локален клон, който трябва да бъде синхронизиран другаде, няма да можете да синхронизирате, освен чрез принудително натискане до отдалечените клонове. Цялото дърво на фиксиране трябва да бъде пренаписано, така че по същество пишете изцяло нова история на отдалечено. Също така ще трябва да се уверите, че всички останали изтеглят ново копие на пренаписаното репо след вашите промени, тъй като и техните репозитории вече няма да са валидни.