С бума на технология, става неизбежно за всеки ИТ специалист да работи върху множество данни едновременно и вашите данни непрекъснато се развиват с времето. Също така е важно да проследите всяка промяна в данните и да сте готови да отмените или върнете всяка нежелана промяна, когато е необходимо.
Трябва да си призная, версирането на данните ми в Git ми позволява да бъда по-експериментален в развитието на проекта си. Ако объркам, знам, че git винаги има начин да отмени и / или да върне тази версия на моя проект към начина, по който беше преди да объркам. Всеки слой е предназначен да позволи на промените в данните да бъдат прегледани и модифицирани и / или коригирани преди преместването на данните в следващия етап. И така, по-долу са грешките, които са разгледани в този блог:
- Нестадийни файлове / директории от Index
- Редактирайте последното съобщено съобщение
- Забравих някои промени в последния коммит
- Отхвърлете местните промени
- Зададени лични данни в местното хранилище
- Заменен последният фиксиране с нов ангажимент
- Предоставих грешни данни
- Върнете се към стария ми проект
- Възстановете изтрит локален клон
- Отмяна на промените, направени при фиксиране
- Дадох грешно име на моя клон
- Искате да пренаредите дневниците на историята, преди да натиснете отдалечено
- Извършени несвързани промени в един ангажимент
- Променете имейл адреса на автора във всички ангажименти във всички клонове
- Загубени и намерени файлове
- Забравих кой клон има моя идентификатор на запис
- Изтрийте фиксиране от историята
- Избута грешен клон към дистанционното
Нестадийни файлове / директории от Index
мощност би срещу таблица 2016
Докато добавяте и / или модифицирате файлове, често сте склонни да използвате поведението по подразбиране на командата ‘git add’, което е да добавите всички файлове и директории към индекса.Много пъти изпитвате нужда да премахнете сцената на определени файлове или да ги промените за последен път, преди да ги извършите.
Синтаксис: git нулиране
Деинсталирането на файлове от зоната на индекса ви дава още една възможност да преработите данните си, преди да се ангажирате с локално репо.
Редактирайте последното съобщено съобщение
Команда: git commit --amend
Можете да редактирате най-новото съобщение за фиксиране, без да създавате ново. За да изброя регистрационните файлове, зададох псевдоним ‘hist’:
Команда: git config --global alias.hist 'log --pretty = format: '% C (жълто)% h% Creset% ad | % C (зелено)% s% Creset% C (червено)% d% Creset% C (синьо) [% an] '--graph --decorate --date = short'x
Не изменяйте съобщението за фиксиране, което вече е изпратено към отдалечено хранилище и споделено с други, тъй като това би направило по-ранната история на фиксиране невалидна и по този начин всяка работа, базирана на това, може да бъде засегната.
Забравих някои промени в последния коммит
Да приемем, че сте забравили да направите някои модификации и вече сте извършили своя моментна снимка, освен това не искате да правите нов ангажимент, за да подчертаете грешката си.
Команда: git commit --amend
Подчертах как пресъздаденият и променен идентификатор на sha-1 на скорошния обект на фиксиране. Престорих се, че съм направил един ангажимент, смесвайки двете промени в едно.
Отхвърлете местните промени
И така, ето случай, в който модифицирах файла „README“ и го организирах. След това модифицирах същия файл за втори път, но осъзнах, че не искам втората промяна.
Сега, нека не отменям ръчно цялата промяна, мога просто да изтегля поетапната версия на файла.
Синтаксис:
git checkout -–Локални промени във файл
git checkout -–Локални промени във всички файлове в директорията & shy & shy
Команда: git checkout - README
И така, отхвърлих последните си промени във файла и приех поетапната версия на файла. При следващото фиксиране само поетапната версия на файла отива в локалното хранилище.
Зададени лични данни в местното хранилище
Искам да премахна определени данни от локалното хранилище, но да запазя файловете в работната директория.
Синтаксис:
git reset --mixed HEAD ~
git reset --mixed
Команда: git reset --mixed HEAD ~ 1
HEAD ~ 1 показва фиксиране непосредствено преди скорошното фиксиране, посочено от текущия клон HEAD.
Файловете в текущата моментна снимка са премахнати както от локалното хранилище, така и от промените. Добавете следните модели в глобалния .gitignore файл, за да ги изключите от проследяване от git.
vim ~ / .gitignore_global
# файлове с парола #
* .pass
* .бутон
* .passwd
С това, коммитът, който е имал моментна снимка на файлове с пароли, се премахва и получавате чиста подредена област. Файловете ми все още присъстват в моята работна директория, но вече не присъстват в локалното хранилище, а също няма да бъдат избутвани в отдалечено хранилище.
Внимание: Ако ги загубите, git не може да ги възстанови вместо вас, тъй като не знае за това.
Заменете последния ангажимент с нов
Синтаксис: git reset --soft [/ HEAD ~ n>]
Опцията ‘–soft’ просто премахва ангажираните файлове от локалното хранилище, докато те все още са индексирани в индекса и можете да ги ангажирате отново след преглед. е sha-1 на моментната снимка, която искате да премахнете от локалното репо. където n е броят на ангажиментите преди фиксацията HEAD
Команда :git reset --soft HEAD ~ 1
Променете файловете и ги поставете отново
Команда: git commit -m 'Добавяне на index.html и style.css'
Историята на вашите ангажименти сега се оказва:
Предоставих грешни данни
Синтаксис:
git reset --hard HEAD ~ n–Настройте проекта на ‘n’ ангажименти преди последната направена моментна снимка
git reset --hard– Нулирайте проекта, за да дадете моментна снимка на идентификатор на фиксиране
Команда: git reset --hard HEAD ~ 1
Последните комити и повредените файлове се премахват от локалното хранилище, промените, както и от работната директория.
Внимание: Това е опасна команда, тъй като в крайна сметка губите файлове в работната директория. Не се препоръчва за отдалечено споделено хранилище.
Върнете се към стария ми проект
Можете да преминете към по-старо състояние на вашия проект в историята на времето. Ако объркате най-новата версия или се нуждаете от подобрения в по-стария код, може да искате да създадете друг клон от старата снимка на проекта, за да не пречите на текущата си работа. Нека да видим как:
а. Избройте историята на проекта и вземете решение за по-стария идентификатор на коммит, команда:отидете история б. Създайте друг клон от идентификатора на фиксиране:
git checkout -b старо състояние e7aa9a5
° С. Продължете да работите по кода и по-късно обединете / пребазирате с клона ‘master’.
Възстановете изтрит локален клон
Възможно е да се регенерира загубената работа на референтен клон. Да речем, изтрих клона ‘old_code’, без да се сливам с основния клон и загубих работата. И не, аз също не избутах клона към отдалечено хранилище, какво тогава? Ами git песни и запазете запис в дневника на всички промени, направени във всяка препратка, да видим моята:отидете да пререгистрирате
И така, HEAD @ {2} е указателят, когато се преместих в клон ‘old_code’, нека възстановим това:
Синтаксис:git checkout -b
Команда:git checkout -b old_code HEAD @ {2}
Вече трябва да сте в клона „old_code“ с най-новата си работа по време на създаването й. Освен това показалецът „reflog“ в HEAD @ {1} е последният ангажимент, направен в клона „old_code“. За да възстановите този уникален commit просто изпълнете командата като:git reset --hard HEAD @ {1}.Това също възстановява модифицираните файлове в работната директория.
Ако искате да знаете подробно как работи тази команда и как можете да управлявате записите ‘reflog’, можете също да прочетете по-ранната ми публикация навъзстановяване на изтрития клон от git reflog.
Отмяна на промените, направени при фиксиране
отивамвръщанесе използва за записване на някои нови фиксирания, за да се обърне ефекта на някои по-ранни фиксирания.
Синтаксис: git revert
От моите дневници за фиксиране бих искал да обърна направената промяна в маркирания идентификатор на фиксиране:
Команда: git revert 827bc0d
goto команда c ++
По-добре е да не нулирате споделените ангажименти „твърдо“, а вместо това да ги „git revert“, за да запазите историята, така че да стане по-лесно за всички да проследят дневниците на историята, за да разберат какво е върнато, от кого и защо?
Можете да използвате същата логика на препращане на фиксиращите данни към указателя HEAD, вместо да задавате идентификатор на фиксиране, както в HEAD ~ 3 или HEAD ~ 4 и т.н.
Дадох грешно име на моя клон
Можете да преименувате име на локален клон. Случва се много пъти, че може да пожелаете да преименувате своя клон въз основа на проблема, по който работите, без да преминавате през болката от мигрирането на цялата си работа от едно място на друго. Например, можете да сте в същия клон или в различен клон и пак да можете да преименувате желания клон, както е показано по-долу:
Синтаксис: git клон -m
Команда: git клон -m old_code old_ # 4920
Както може би се чудите дали git поддържа запис на това преименуване? Да, отнася се за вашите записи за „пренаписване“, ето моите:
Преименуването на клон няма да засегне неговия клон за дистанционно проследяване. Ще видим в отдалечения раздел как да заменим клон на отдалеченото хранилище
Пренаредете дневниците на историята, преди да натиснете отдалечено
Как ми се иска да бях направил определени ангажименти по-рано от други и изобщо не бих направил някои ангажименти. Интерактивно пренареждайте и редактирайте старите ангажименти за ефективно коригиране или подобряване на кода
Синтаксис: git rebase -i
Команда: git rebase -i fb0a90e–Стартирайте пребазирането на ангажиментите, направени след идентификационния номер на fb0a90e
Посетете отново git rebase документация, за да се разбере как се различава ‘–интерактивна или -i’ база от обикновена база.
Извършени несвързани промени в един ангажимент
В този случай трябва да разделите стар заровен ангажимент на множество логически фиксирания.
Синтаксис: git rebase -i
Команда: git rebase -i fb0a90e
В редактора на rebase трябва да изберете e7aa9a5 идентификатор на ангажимент и да го промените на ‘edit’ вместо ‘pick’.
Сега ще бъдете във версията на проекта на commit id-e7aa9a5. Първо, нулирайте историята на фиксиране и областта за подреждане до предишната команда за команди:git reset HEAD ~ 1
Второ, редактирайте + етап + ангажирайте файловете поотделно
Команди:
git add code && git commit -m 'Добавяне на начални кодове'
git add newcode && git commit -m 'Добавяне на нов код'
Трето, продължете пребазирането и завършете.
Команда :git rebase - продължи
Четвърто, прегледайте историята с допълнителни ангажименти.
Команда: отидете история
Променете имейл адреса на автора във всички ангажименти във всички клонове
Отдавна правя версии и фиксирам моите файлове на проекти в git, но досега никога не ми направи впечатление, че имейл адресът ми е бил компрометиран в дневниците на историята ми на коммити, които дори се публикуват в отдалечени хранилища. Е, това може да се случи на всеки, когато първоначално настроите конфигурациите във файла „.gitconfig“. До моето облекчение git може нова редакция променливите на средата, които предоставяме при създаване на обект за фиксиране.
Първо получавам списъка с имейл адреси да реша тези, които искам да променя:
Команда: git log --all --pretty = format: '% an% d'–Това отпечатва име на автор (refname / име на клон)
Второ, минавам всеки ангажимент за всеки клон и пренапишете обекта за фиксиране с новия имейл идентификатор
Команда:
git filter-branch --env-filter '
ако ['$ GIT_AUTHOR_NAME' = 'divya']
тогава
GIT_AUTHOR_EMAIL = 'divya@github.com'
бъда
' -- --всичко
Загубени и намерени файлове
Да предположим, че сте загубили определен файл и не помните името му, но бихте могли да извикате определени думи във файла. В този случай можете да следвате тези стъпки-
Етап 1: Избройте всички ангажименти, които някога са съдържали моментната снимка на файла, с търсения модел
Команда :git rev-list --all | xargs git grep -i 'клеймо за време'
Стъпка 2 : Създайте нов клон „загубен-намерен“ от този подчертан идентификатор на ангажимент
Синтаксис: git checkout -b загубен-намерен d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f
Забравих кой клон има моя идентификатор на запис
Понякога, след като откриете идентификационен номер на бъги, можете да пожелаете да знаете всички клонове, които имат този фиксиран запис, за да можете да ги поправите всички. Проверката на историята на всеки клон не е много практична в голям мулти-клон проект.
Лош ангажимент, направен в приложението ми за навигационна сграда, веднъж счупи кода, тогава използвах Команда ‘git bisect’ за откриване на лош идентификатор на фиксиране последвано откоманда:git клон --съдържаза да изброите клоновете с този лош коммит.
И така, сега знам всички клонове, които все още имат лош ангажимент, бих могъл или да върна, или да нулирам този набор от промени.
тип функция в sql
Изтрийте фиксиране от историята
Понякога изпитвам нужда просто да изтрия ангажимент от историята и да не оставя следа от него. Не бих ви препоръчал да изпробвате тази каскада на споделен клон, а само на местния клон.
Синтаксис: git rebase -i
Команда :git rebase -i 93859d8
В редактора на rebase-> заменете ‘edit’ с ‘drop’ за маркирания идентификатор на ангажиране: 69f4813
В някои от случаите това пренаписване може да доведе до конфликти. Трябва да разрешите конфликти, след което продължете по-нататък.
Внимание : Това е опасна команда, тъй като това презаписва историята и може да загуби данни. Такъв клон се различава от отдалечения си аналог и ще трябва да бъде натиснат с- силаили- принудително наеманеопция.
Избута грешен клон към дистанционното
Сега ето какво искам да направя - искам да изтрия a отдалечен клон и също така да спра да го проследявам от местния ми клон. “git push‘Команда, когато се използва с--Изтрийопцията изтрива отдалечения клон И така, по този начин получавам локалното копие на клонирания проект -
git clone https://github.com/greets/myProj.git
cd myProj
След като отдалеченият клон бъде изтрит, други в споделеното репо трябва да обновят и актуализират своите отдалечени препратки с- сини сливиопция за изтриване на липсващите препратки към обект:git fetch --prune -v произход
В тази публикация споменах някои от често срещаните грешки или промени, които git може да ви помогне да поправите. Всеки код е уникален и разработен по свой начин, така че има и различни начини за подход и отстраняване на проблем. Винаги можете да се обърнете към длъжностното лице git документация за да разберете как различни git команди защитават вашия изходен код и как да използвате командите по възможно най-добрия начин.
След като разбрахте често срещаните грешки на Git, вижте това от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение за сертифициране на Edureka DevOps помага на обучаващите се да разберат какво е DevOps и да придобият опит в различни процеси и инструменти на DevOps като Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack и GIT за автоматизиране на множество стъпки в SDLC.
Имате въпрос към нас? Моля, споменете го в раздела за коментари на тази „често срещани грешки в Git“ и ние ще се свържем с вас