Топ 40 въпроси и отговори за интервю за GIT през 2021 г.

top 40 git interview questions

Най-популярните въпроси за интервю за GIT с отговори и примери:

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

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

Да започваме!!

Най-често задавани въпроси за интервю за GIT

По-долу са посочени някои от често задаваните въпроси за интервю за GIT за справка.

В # 1) Какво е Git?

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

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

В # 2) Какво представлява разпределена система за контрол на версиите?

Отговор: Разпределеният VCS е система, която не зависи от централния сървър, за да запази проектния файл и всички негови версии. В разпределения VCS всеки сътрудник или разработчик получава локално копие на основното хранилище и това се нарича клонинг.

(изображение източник )

Както можете да видите в горната диаграма, всеки сътрудник поддържа локално хранилище на своите локални машини. Те могат да ангажират и актуализират локалните хранилища без никакви проблеми.

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

В # 3) Кой е създал Git?

Отговор: Git е създаден от Linus Torvalds през 2005 г. по пътя към разработването на Linux Kernel.

В # 4) Кой език се използва в Git?

Отговор: C е основният език за програмиране, на който е написан Git. Езикът C прави Git бърз, като избягва режийните разходи по време на изпълнение, свързани с други езици за програмиране на високо ниво.

В # 5) Какви са предимствата / основните характеристики на Git?

Отговор: По-долу са включени различните f хранене на Git.

(i) Безплатен и отворен код:

Git се издава под лиценза на GPL (General Public License) с отворен код. Не е нужно да плащате нищо, за да използвате Git.

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

(ii) Скорост:

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

Git е написан на C, който е основният език за програмиране, който избягва режийните разходи по време на изпълнение, свързани с други езици на високо ниво.

(iii) Мащабируемо:

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

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

(iv) Надежден:

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

(v) Сигурно:

Git използва SHA1 (Secure Hash Function) за именуване и идентифициране на обекти вътре в своето хранилище. Всеки артефакт и ангажимент се сумират и възстановяват чрез контролната му сума по време на плащане.

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

(vi) Икономически:

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

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

какво vr работи с xbox one

(vii) Поддържа нелинейно развитие:

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

Git Branches са изключително леки. Клон в Git се отнася само до един коммит. Пълната структура на клонове може да бъде създадена с помощта на родителски ангажименти.

(viii) Лесно разклоняване:

Управлението на клонове чрез Git е много лесно и лесно. За създаването, изтриването и обединяването на клонове са необходими само няколко джифита. Клоновете на характеристиките дават изолирана среда на всяка промяна във вашата кодова база.

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

(ix) Разпределено развитие:

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

(x) Съвместимост заедно с настоящите системи или протокол:

Хранилищата могат да бъдат публикувани чрез HTTP, FTP или Git протокол върху обикновен сокет или ssh.

В # 6) Как се създава хранилище в Git?

Отговор: За да създадете хранилище, трябва да създадете директория за проекта, ако той все още не съществува, и след това просто да изпълните командата „ git init ”. Чрез изпълнението на тази команда в директорията на проекта ще бъде създадена директория .git, т.е. сега вашата директория на проекта се превърна в хранилище на Git.

В # 7) Какво е .git директория?

Отговор: В момента, в който създадете хранилище, ще намерите в него директория .git. Тази директория .git съдържа всички метаданни на хранилището и поддържа проследяване на всички промени, направени във файловете във вашето хранилище, като поддържа история на фиксиране.

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

В # 8) Какво се случва, ако директорията .git бъде изтрита?

Отговор: Ако директорията .git / бъде изтрита, ще загубите историята на проекта си. Хранилището вече няма да бъде под контрол на версиите.

В # 9) Коя команда се използва за писане на съобщение за ангажиране в Git?

Отговор: Командата, използвана за предаване на съобщение към git commit е git commit -m „съобщение за ангажиране“. Знамето м се използва за предаване на съобщение за фиксиране.

В # 10) Какво е голото хранилище на Git? По какво се различава от стандартното / неоткрито хранилище на Git?

Отговор: Хранилища, които са създадени чрез git init команда са стандартните / неоткрити хранилища на Git.

В папката от най-високо ниво на такова хранилище ще намерите две неща:

1. Поддиректория .git, съхраняваща всички метаданни и проследяване на историята на вашето репо.
2. Работещо дърво.

Хранилищата, които са създадени с помощта на git init –bare команда са известни като голи Git хранилища. Те се използват главно за споделяне. Те не съдържат нито едно работещо дърво. Те пазят историята на ревизиите на git на вашето хранилище в основната папка, вместо да го имат в подпапката .git.

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

Тъй като голото хранилище не съдържа никакво работно пространство, git push и git pull командите не работят при голо репо. Не се изисква да извършвате каквито и да е промени в голо репо.

В # 11) Споменете някои услуги за хостинг на Git Repository.

Отговор:

• Github
• Пикакод
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• LaunchPad
• Изпълнявайте
• Фасул
• Изглежда като

В # 12) Назовете някои основни операции в Git.

Отговор: Някои основни операции в Git включват:

• Инициализирайте
• Добавяне
• Ангажирайте се
• Натиснете
• Издърпайте

В # 13) Назовете някои разширени операции в Git.

Отговор: Някои разширени операции в Git са:

• Разклоняване
• Сливане
• Пребазиране

В # 14) Как ще правите разлика между Git и SVN?

Отговор: Git е разпределен контрол на версиите, докато SVN е централизиран. Това води до много разлики между двете по отношение на техните характеристики и функционалности.

В # 15) Как ще правите разлика между Git и GitHub?

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

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

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

Също така, GitHub е с отворен код, т.е.кодът се съхранява на централизиран сървър и може да бъде достъпен от всеки.

В # 16) Какво представлява конфликт в Git и как да го разрешим?

Отговор: Git има функция за автоматично обединяване, която се справя самостоятелно с обединяването, при условие че промените в кода са настъпили в различни редове и в различни файлове.

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

В такива случаи се изисква вашата помощ, за да решите кой код да включите и кой код да изхвърлите при окончателното сливане.

Конфликт на сливане може да възникне по време на обединяване на клон, пребазиране на клон или избор на коммит. След като бъде открит конфликт, Git подчертава конфликтната област и ви моли да го разрешите. След като конфликтът бъде разрешен, можете да продължите с обединяването.

Следвайте стъпките по-долу, за да разрешите конфликт на конфликт на сливане на промяна на линия:

1. Отворете Git Bash (команден ред Git).
2. Използвайте CD команда, за да отидете в локалното хранилище на Git, което има конфликт на сливане.
3. Използвай git статус команда за създаване на списък с файлове, засегнати от конфликта на сливане.
4. Отворете текстовия редактор, който използвате, и преминете към файла, който има конфликти на обединяване.
5. За да видите началото на конфликта на сливане във вашия файл, потърсете документа за маркера за конфликт<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> ИМЕ НА КЛОНА.
6. Изберете в случай, че трябва да запазите само промените на вашия клон, просто запазете промените на другия клон или направете нова промяна, която може да включва промени от двата клона. Изтрийте маркерите за конфликт<<<<<<>>>>>> и направете промените, които са ви необходими при окончателното сливане.
7. Използвайте git добавя. команда, за да добавите или поетапно промените.
8. И накрая, използвайте git commit -m „съобщение“ команда за ангажиране на вашите промени с коментар.

За да разрешите конфликта на обединен файл, трябва да изпълните следните стъпки:

1. Отворете Git Bash (команден ред Git).
2. Използвайте CD команда, за да отидете в локалното хранилище на Git, което има конфликт на сливане.
3. Използвай git статус команда за създаване на списък с файлове, засегнати от конфликта на сливане.
4. Отворете текстовия редактор, който използвате, и преминете към файла, който има конфликти на обединяване.
5. Изберете дали искате да запазите премахнатия файл. Можете да проверите най-новите промени, извършени в премахнатия файл във вашия текстов редактор.
6. Използвайте git add команда за добавяне на премахнатия файл обратно в хранилището. Или използвайте върви команда за премахване на файла от хранилището ви.
7. И накрая, използвайте git commit -m „съобщение“ команда за ангажиране на вашите промени с коментар.

Въпрос # 17) Как ще коригирате счупен ангажимент?

Отговор: За да коригирате счупен ангажимент или да промените последния ангажимент, най-удобният метод е да използвате командата „ git commit -amend ’ .

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

(изображение източник )

Чрез тази команда можете също да редактирате предишното съобщение за фиксиране, без да променяте неговата моментна снимка.

В # 18) Каква е ползата от git instaweb?

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

Този скрипт настройва gitweb и уеб сървър за сърфиране в локалното хранилище. Той автоматично насочва уеб браузър и стартира уеб сървър през интерфейс във вашето локално хранилище.

В # 19) Какво е git is-tree?

кой е най-добрият безплатен имейл

Отговор: ‘Git is-tree’ означава обект на дърво, съдържащ режима и името на всички елементи, заедно със стойността SHA-1 на петно ​​или дърво.

Q # 20) Има ли начин да се върне git коммит, който вече е прокаран и публично достъпен?

Отговор: Да, за коригиране или връщане на лош ангажимент има два подхода, които могат да се използват въз основа на сценария.

Те са:

1. Много очевидният начин е да направите нов ангажимент, когато премахнете лошия файл или поправите грешките в него. След като приключите, можете да го изпратите до отдалечено хранилище.
2. Друг подход е да се създаде нов ангажимент, за да се отменят всички промени, направени в предишния лош ангажимент. Това може да стане чрез командата git revert - “ git revert '

Q # 21) Как ще правите разлика между git pull и git fetch?

Отговор: Git pull команда изтегля всички нови фикси от определен клон в централното хранилище и прави актуалния целевия клон във вашето локално хранилище.

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

Ако искате да видите тези промени в целевия си клон, тогава трябва да изпълните a отидете да се слеете след git fetch. Целевият клон ще бъде актуализиран с последните промени само след обединяването му с извлечения клон.

Така че, git pull актуализира локалния клон с отдалечената му версия, докато git извличането не променя директно вашия собствен локален клон или работно копие под препоръки / глави. Git fetch може да се използва за актуализиране на вашите клонове за дистанционно проследяване под refs / дистанционни //.

С прости думи, git pull е равно на git fetch, последвано от git merge .

Въпрос # 22) Каква е ползата от Staging area или Indexing в Git?

Отговор: От гледна точка на Git има три области, в които могат да се съхраняват промените във файла, т.е. работна директория, подреждане и хранилище.

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

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

След като потвърдите промените си и се отпишете от променената сцена, можете най-накрая да извършите промените. При фиксиране те отиват в локалното хранилище, т.е.в директорията .git / objects.

Ако използвате Git GUI, ще видите опцията за поетапно въвеждане на промените. В екранната снимка по-долу файлът sample.txt е в областта на нестадийни промени, което означава, че е във вашата работна директория.

Можете да изберете файл и да щракнете върху „етап се промени“, след което той ще бъде преместен в зоната за поставяне. Например , файлът hello.txt присъства в променената (ще се ангажира) област. Можете да проверите промените си и след това да направите излизане, последвано от фиксиране.

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

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

В # 23) Какво е Git Stash?

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

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

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

В # 24) Какво представлява падането на Git Stash?

Отговор: Когато вече не се нуждаете от конкретно скривалище, можете да го премахнете, като изпълните git stash команда за пускане . Ако искате да премахнете всички скривалища с едно движение от хранилището, можете да стартирате команда за изчистване на git stash .

В # 25) Какво представлява Git stash apply? По какво се различава от Git stash pop?

Отговор: И двете команди се използват за повторно прилагане на скритите ви промени и започване на работа от мястото, което сте оставили.

В git stash се прилага команда, промените ще бъдат приложени отново към вашето работно копие и също така ще бъдат запазени в скривалището. Тази команда може да се използва, когато искате да приложите едни и същи скрити промени към множество клонове.

В git stash pop команда, промените се премахват от скривалището и се прилагат отново към работното копие.

В # 26) Каква е ползата от командата git clone?

Отговор: The git клонинг команда създава копие на съществуващото централно хранилище на Git във вашата локална машина.

В # 27) Кога се използва командата git config?

Отговор: The git config команда се използва за задаване на опции за конфигурация за вашата инсталация на Git.

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

$ git config –global user.name “”

$ git config –global user.email “”

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

В # 28) Как ще установите дали клонът вече е обединен в главен?

Отговор:

Изпълнявайки командите по-долу, можете да се запознаете със състоянието на сливане на клона:

1. git клон - обединен мастер: Това ще изброи всички клонове, които са преименувани в master.
2. git клон - обединен: Това ще изброи всички клонове, които са обединени в HEAD.
3. git клон - не е обединен: Това ще изброи всички клонове, които все още не са обединени.

По подразбиране тази команда казва състоянието на обединяване само на локални клонове. Ако искате да знаете както за локалното, така и за отдалеченото състояние на обединяване на клонове, тогава можете да използвате -да се флаг. Ако искате да проверите само за отдалечени клонове, тогава можете да използвате -r флаг.

В # 29) Какво представляват куките в Git?

Отговор: Git hooks са определени скриптове, които Git изпълнява преди или след събитие като фиксиране, натискане, актуализиране или получаване. Ще намерите папката ‘hooks’ в директорията .git във вашето локално хранилище. Тук ще намерите скриптове за вграждане, предварително ангажиране, след фиксиране, предварително натискане, след натискане.

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

В # 30) Каква е ползата от git fork? По какво се различава форкирането от клонирането?

Отговор: Раздвояването на проект означава създаване на отдалечено копие от оригиналното хранилище от страна на сървъра. Можете да преименувате това копие и да започнете да правите нов проект около него, без да засягате оригиналния проект. Вилицата не е основната концепция на Git.

Операцията за разклоняване се използва от Git workflow и тази идея съществува по-дълго за безплатен софтуер с отворен код като GitHub. Като цяло, след като раздвоите проекта, рядко ще допринесете отново за родителския проект.

Например, OpenBSD е подобна на Unix операционна система с отворен код, която е разработена чрез форкиране на NetBSD, която е друга подобна на Unix операционна система с отворен код.

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

При раздвоеното копие всички основни данни, като кодове и файлове, се копират от оригиналното хранилище, но клоновете, заявките за изтегляне и други функции не се копират. Forking е идеален начин за сътрудничество с отворен код.

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

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

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

Въпрос # 31) Как ще разберете какви файлове са били променени в даден Git коммит?

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

git diff-tree -r {хеш}

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

Можете също да използвате командата по-долу:

git diff-tree –no-commit-id –name-only -r {хеш}

–No-commit-id ще преквалифицира хеш номерата на фиксиране, за да влезе в изхода. Като има предвид, че -name ще изключи файловите пътища и ще даде имената на файловете само в изхода.

Q # 32) Каква е разликата между git checkout (име на клон) и git checkout -b (име на клон)?

Отговор: Командата git checkout (име на клон) ще премине от един клон на друг.

Командата git checkout -b (име на клон) ще създаде нов клон и също ще премине към него.

В # 33) Какво е SubGit?

Отговор: SubGit е инструмент, който се използва за SVN към Git Migration. Той е разработен от компания, наречена TMate. Той преобразува SVN хранилищата в Git и ви позволява да работите едновременно и върху двете системи. Той автоматично синхронизира SVN с Git.

(изображение източник )

Можете да създадете SVN || Git огледало с помощта на този инструмент. SubGit трябва да бъде инсталиран на вашия Git сървър. Той ще открие всички настройки на вашето отдалечено SVN хранилище, включително SVN ревизии, клонове и тагове, и ги конвертира в Git комити.

Той също така запазва историята, включително проследяване на данни за сливане.

В # 34) Можете ли да възстановите изтрит клон в Git?

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

Когато изтриете клон, получавате SHA, показан на терминала:

Изтрит клон (беше)

Можете да използвате командата по-долу, за да възстановите изтрития клон:

git checkout -b

Ако не знаете SHA за фиксирането на върха на вашия клон, можете първо да използвате отидете да пререгистрирате команда, за да знаете стойността на SHA и след това да приложите горната команда за плащане, за да възстановите вашия клон.

В # 35) Какво е git разл команда? По какво се различава от git статус?

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

The git статус команда се използва за проверка на хранилище. Той показва състоянието на работната директория и зоната за подреждане. Той ще изброи файловете, които са били инсценирани, които не са били инсценирани и файловете, които не са проследени.

Въпрос # 36) Какво съдържа обектът Comm?

Отговор: Обектът за фиксиране съдържа хеш на обект на дърво от най-високо ниво, хеш за ангажиране на родител (ако има такъв), информация за автор и комитер, дата на фиксиране и съобщение за фиксиране

Можете да видите това чрез git дневник команда.

Пример:

(изображение източник )

В # 37) Какво представлява git cherry-pick? Какви са сценариите, в които може да се използва git cherry-pick?

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

git cherry-pick commitSha е командата, използвана за бране на череши. commitSha е препратката към фиксиране.

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

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

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

В # 38) За какво се използва „git reset“? Какъв е режимът по подразбиране на тази команда?

най-доброто приложение за проверка на темп на процесора

Отговор: Git нулиране е мощна команда за отмяна на локални промени в състоянието на Git репо. Тази команда нулира текущата HEAD до посочения етап.

Той нулира както индекса, така и работната директория до състоянието на последния ви коммит. Git reset има три режима, т.е. мек, твърд и смесен. Режимът на работа по подразбиране е смесен.

В # 39) Каква е разликата между ‘HEAD’, ‘working tree’ и ‘index’?

Отговор: Работното дърво или работното пространство е директорията, съдържаща изходните файлове, по които работите в момента.

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

Този файл присъства в /.git/index. HEAD е препратката или указателят към последния фиксиране в текущия клон за плащане.

Q # 40) Каква е разликата между rebase и merge? Кога трябва да пребазирате и кога да обедините?

Отговор: Командите rebase и merge се използват за интегриране на промените от един клон в друг, но по различен начин.

Както се вижда от двете изображения по-долу, да предположим, че имате ангажименти (това е преди сливане / пребазиране). След сливането ще получите резултата като комбинация от ангажименти. Той свързва историята на двата клона и създава нов „комбиниране на ангажимент“ в клона на характеристиките.

От друга страна, rebase ще премести целия клон на характеристиките, за да започне от върха на главния клон.

(изображение източник )

Ангажиментите ще изглеждат така:

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

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

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

Обединяването продължава историята, каквато е, докато пребазирането пренаписва историята. По този начин, ако искате да видите историята напълно такава, каквато е възникнала, трябва да използвате сливане.

В # 41) Какъв е синтаксисът за пребазиране?

Отговор: Синтаксисът на командата rebase е git rebase (нов ангажимент)

В # 42) Как ще премахнете файл от Git, без действително да го премахнете от вашата локална файлова система?

Отговор: Можете да използвате опцията ‘кеширан’ за това:

git rm -rf –кеширани $ FILES

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

В # 43) Какъв е често срещаният модел на разклоняване в Git?

Отговор: Общият модел на разклоняване се основава на git-потока. Той има два основни клона, т.е.устройство и развитие.

• Главният клон съдържа производствения код. Целият код за разработка се обединява в главния клон в даден момент от времето.
• Клонът за разработка съдържа предпроизводствения код. Когато функциите са завършени, те се сливат с главния клон, обикновено чрез CI / CD тръбопровод.

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

• Основни клонове / Тематични клонове: Те се използват за разработване на нови функции за предстоящите издания. Той може да се разклони от клона за разработка и трябва да бъде обединен обратно в клона за разработка. Като цяло тези клонове съществуват само в хранилища за програмисти, а не в произход.
• Клонове с актуални корекции: Те се използват за непланирано производство, когато има нужда да се коригира всяка критична грешка незабавно във версията на прод. Те могат да се разклонят от master и трябва да бъдат обединени обратно в разработване и master.
• Клонове на издаване: Те се използват за подготовката на ново производствено издание. Клонът за издание ви позволява да поправяте незначителни грешки и да подготвяте метаданни за издаване. Те могат да се разклонят от развитието и трябва да бъдат обединени обратно в master и развитие.

Заключение

Преминахме през важните въпроси, които обикновено се задават по време на интервюта за Git в този урок.

Това не само ще ви помогне да се подготвите за предстоящите интервюта, но и ще изясни вашите git концепции.

Всичко най-добро за вашето интервю!

Препоръчително четене

• Интервюирайте въпроси и отговори
• Някои интересни въпроси за интервю за тестване на софтуер
• Топ 40 C Въпроси и отговори за интервю за програмиране
• Топ 40 популярни въпроси и отговори за интервю за J2EE, които трябва да прочетете
• Въпроси и отговори за интервю за ETL тестване
• 20+ Най-често задавани въпроси и отговори от интервю за изход
• Водещи въпроси за интервюта за формуляри и доклади на Oracle
• Някои сложни ръчни тестови въпроси и отговори