40 najpopularniejszych pytań i odpowiedzi do wywiadów GIT w 2021 r

top 40 git interview questions

Najpopularniejsze pytania do wywiadów GIT z odpowiedziami i przykładami:

Ten samouczek informacyjny zawiera zestaw najczęściej zadawanych pytań w wywiadach Git wraz z opisowymi odpowiedziami. Te pytania z pewnością pomogą Ci przygotować się do każdej rozmowy kwalifikacyjnej Git i pomyślnie ją złamać.

Niezależnie od tego, czy jesteś nowicjuszem, czy doświadczonym profesjonalistą, te pytania do wywiadów w Git i szczegółowe odpowiedzi z pewnością pomogą Ci wzbogacić swoją wiedzę na ten temat i osiągnąć sukces w pracy, a także podczas wywiadów.

Zacznijmy!!

Najczęściej zadawane pytania do wywiadów GIT

Poniżej wymieniono niektóre z najczęściej zadawanych pytań podczas rozmowy kwalifikacyjnej GIT w celach informacyjnych.

Pytanie 1) Co to jest Git?

Odpowiedź: Git to rozproszone narzędzie kontroli wersji. Jest kompatybilny z rozproszonymi nieliniowymi przepływami pracy, ponieważ zapewnia pewność danych do budowy oprogramowania dobrej jakości.

Git jest darmowy i open-source. Może być używany do prawie każdego rodzaju projektów, zarówno małych, jak i dużych. Git jest znany z dużej szybkości i wydajności. Repozytoria Git są bardzo łatwe do znalezienia i uzyskania do nich dostępu. Dzięki pewnym funkcjom Git jest wysoce elastyczny, bezpieczny i kompatybilny z Twoim systemem.

P # 2) Co to jest rozproszony system kontroli wersji?

Odpowiedź: Rozproszony VCS to system, który nie jest zależny od centralnego serwera w zakresie przechowywania pliku projektu i wszystkich jego wersji. W rozproszonym systemie VCS każdy współpracownik lub programista otrzymuje lokalną kopię głównego repozytorium i nazywa się to klonem.

(wizerunek źródło )

Jak widać na powyższym diagramie, każdy współpracownik utrzymuje lokalne repozytorium na swoich lokalnych komputerach. Mogą zatwierdzać i aktualizować lokalne repozytoria bez żadnych problemów.

Korzystając z operacji ściągania, programista może zaktualizować swoje repozytorium lokalne o najnowsze zmiany z serwera centralnego. Korzystając z operacji wypychania, mogą wysyłać swoje zmiany z lokalnego repozytorium do centralnego serwera.

P # 3) Kto stworzył Git?

Odpowiedź: Git został stworzony przez Linusa Torvaldsa w 2005 roku na drodze do rozwijania jądra Linuksa.

Pytanie 4) Jaki język jest używany w Git?

Odpowiedź: C jest podstawowym językiem programowania, w którym napisano Git. Język C sprawia, że ​​Git jest szybki, unikając narzutów czasu wykonywania powiązanych z innymi językami programowania wysokiego poziomu.

Pytanie 5) Jakie są zalety / główne cechy Git?

Odpowiedź: Poniżej wymieniono różne f cechy Git.

(i) Bezpłatne i otwarte źródło:

Git jest wydawany na licencji open source GPL (General Public License). Nie musisz nic płacić, aby korzystać z Git.

To jest całkowicie bezpłatne. Ponieważ jest to oprogramowanie typu open source, możesz modyfikować kod źródłowy zgodnie ze swoimi potrzebami.

(ii) Prędkość:

Ponieważ nie musisz łączyć się z żadną siecią w celu wykonania wszystkich działań, szybko wykonuje wszystkie zadania. Pobieranie historii wersji z repozytorium przechowywanego lokalnie może być sto razy szybsze niż pobieranie jej z serwera zdalnego.

Git jest napisany w C, który jest podstawowym językiem programowania, który unika narzutów czasu wykonywania powiązanych z innymi językami wysokiego poziomu.

(iii) Skalowalne:

Git jest wysoce skalowalny. Jeśli więc liczba współpracowników wzrośnie w nadchodzącym czasie, Git może z łatwością dostosować się do tej zmiany.

Pomimo faktu, że Git reprezentuje całe repozytorium, dane przechowywane po stronie klienta są bardzo małe, ponieważ Git kompaktuje całe ogromne dane za pomocą techniki bezstratnej kompresji.

(iv) Niezawodny:

Ponieważ każdy współpracownik ma własne repozytorium lokalne, w przypadku awarii systemu utracone dane można odzyskać z dowolnego lokalnego repozytorium. Zawsze będziesz mieć kopię zapasową wszystkich swoich plików.

(v) Bezpieczne:

Git wykorzystuje SHA1 (Secure Hash Function) do nazywania i identyfikowania obiektów w swoim repozytorium. Każdy artefakt i zatwierdzenie są sumowane i odzyskiwane przez sumę kontrolną podczas realizacji transakcji.

Historia Git jest zapisywana w sposób, w którym identyfikator określonej wersji (zatwierdzenie w rozumieniu Git) zależy od całkowitej historii rozwoju prowadzonej do tego zatwierdzenia. Gdy wersja pliku zostanie przesłana do Gita, nie ma możliwości jej zmiany bez zauważenia.

(vi) Ekonomiczne:

W przypadku scentralizowanego systemu kontroli wersji, serwer centralny musi być wystarczająco silny, aby obsługiwać żądania całego zespołu. Nie stanowi to problemu dla mniejszych zespołów, jednak wraz z rozwojem zespołu ograniczenia sprzętowe serwera mogą wpływać na wydajność.

W przypadku rozproszonych systemów kontroli wersji, takich jak Git, członkowie zespołu nie wymagają interakcji z serwerem w oczekiwaniu, kiedy będą musieli wypychać lub pobierać zmiany. Całe podnoszenie ciężarów odbywa się po stronie klienta, dlatego sprzęt serwera z pewnością może być dość prosty.

(vii) Obsługuje rozwój nieliniowy:

Git zapewnia szybkie rozgałęzianie i scalanie oraz zawiera specjalne narzędzia do przewidywania i przemierzania nieliniowej historii rozwoju. Podstawowym założeniem w Git jest to, że zmiana będzie scalana częściej niż jest zapisywana, ponieważ jest wysyłana do różnych recenzentów.

Git Branches są niezwykle lekkie. Gałąź w Git odnosi się tylko do pojedynczego zatwierdzenia. Pełną strukturę gałęzi można utworzyć za pomocą zatwierdzeń nadrzędnych.

(viii) Łatwe rozgałęzianie:

Zarządzanie oddziałami przez Git jest bardzo proste i łatwe. Tworzenie, usuwanie i łączenie gałęzi wymaga zaledwie kilku chwil. Gałęzie funkcji zapewniają izolowane środowisko dla każdej zmiany w bazie kodu.

Gdy deweloper wymaga rozpoczęcia pracy nad czymś, bez względu na wielkość pracy, tworzy nową gałąź. Daje to pewność, że gałąź główna stale posiada kod jakości produkcyjnej.

(ix) Rozproszone tworzenie:

Git zapewnia każdemu deweloperowi lokalną kopię całej historii rozwoju, a zmiany są klonowane z jednego takiego repozytorium do drugiego. Zmiany te są wprowadzane jako dodane gałęzie rozwoju i można je łączyć w taki sam sposób, jak gałąź rozwijana lokalnie.

(x) Zgodność z obecnymi systemami lub protokołami:

Repozytoria mogą być publikowane za pośrednictwem protokołu HTTP, FTP lub Git na wierzchu zwykłego gniazda lub ssh.

P # 6) Jak utworzyć repozytorium w Git?

Odpowiedź: Aby utworzyć repozytorium, musisz utworzyć katalog dla projektu, jeśli jeszcze nie istnieje, a następnie po prostu wykonać polecenie „ git init ”. Wykonując to polecenie, katalog .git zostanie utworzony w katalogu projektu, tj. Teraz katalog projektu zamienił się w repozytorium Git.

P # 7) Co to jest katalog .git?

Odpowiedź: W momencie tworzenia repozytorium, znajdziesz w nim katalog .git. Ten katalog .git zawiera wszystkie metadane repozytorium i utrzymuje ścieżkę wszystkich zmian dokonanych w plikach w repozytorium, zachowując historię zatwierdzeń.

Wszystkie informacje dotyczące zatwierdzeń, hooków, referencji, baz danych obiektów, adresów zdalnych repozytoriów itp. Są przechowywane w tym folderze. To jest najważniejsza część Gita. Kiedy klonujesz repozytorium Git na komputerze lokalnym, ten plik .git jest katalogiem, który faktycznie jest kopiowany.

P # 8) Co się stanie, jeśli katalog .git zostanie usunięty?

Odpowiedź: Jeśli katalog .git / zostanie usunięty, stracisz kontrolę nad historią swojego projektu. Repozytorium nie będzie już objęte kontrolą wersji.

P # 9) Które polecenie jest używane do pisania komunikatu zatwierdzenia w Git?

Odpowiedź: Polecenie użyte do przekazania wiadomości do zatwierdzenia git to git commit -m „komunikat o zatwierdzeniu”. Flaga m służy do przekazywania komunikatu o zatwierdzeniu.

P # 10) Co to jest nagie repozytorium Git? Czym różni się od standardowego / nieoczyszczonego repozytorium Git?

Odpowiedź: Repozytoria utworzone za pośrednictwem git init Polecenie to standardowe / nie-nagie repozytoria Git.

W folderze najwyższego poziomu takiego repozytorium znajdziesz dwie rzeczy:

1. Podkatalog .git przechowujący wszystkie metadane i śledzący historię repozytorium.
2. Drzewo robocze.

Repozytoria utworzone za pomocą git init –bare są znane jako repozytoria Git. Są używane głównie do udostępniania. Nie zawierają żadnego drzewa roboczego. Przechowują historię wersji git repozytorium w folderze głównym, a nie w podfolderze .git.

Zawiera tylko dane repozytorium. W ten sposób zwykłe repozytorium Git różni się od standardowego repozytorium Git. Ponadto nagie repozytorium nie ma domyślnego pilota pochodzenie repozytorium, ponieważ służy jako repozytorium pochodzenia dla wielu użytkowników zdalnych.

Ponieważ czyste repozytorium nie zawiera żadnego obszaru roboczego, plik git push i git pull polecenia nie działają w przypadku samego repozytorium. Nie musisz dokonywać żadnych zmian w samym repozytorium.

Pytanie 11) Wspomnij o usługach hostingu repozytorium Git.

Odpowiedź:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• Wyrzutnia
• Z konieczności
• Łodyga fasoli
• To wygląda jak

P # 12) Nazwij kilka podstawowych operacji w Git.

Odpowiedź: Niektóre podstawowe operacje w Git obejmują:

• Zainicjuj
• Dodaj
• Popełnić
• Pchać
• Ciągnąć

Q # 13) Wymień niektóre zaawansowane operacje w Git.

Odpowiedź: Niektóre zaawansowane operacje w Git to:

• Rozgałęzienie
• Łączenie
• Rebasing

P # 14) Jak odróżnisz Git od SVN?

Odpowiedź: Git to rozproszona kontrola wersji, podczas gdy SVN jest scentralizowana. Prowadzi to do wielu różnic między nimi pod względem ich cech i funkcjonalności.

Pytanie # 15) Jak rozróżnisz Git i GitHub?

Odpowiedź: Git to wysokiej jakości system kontroli wersji. Jest rozpowszechniany w naturze i służy do śledzenia zmian w kodzie źródłowym podczas tworzenia oprogramowania. Posiada unikalny model rozgałęziania, który pomaga w synchronizowaniu pracy między programistami i śledzeniu zmian w dowolnych plikach.

Podstawowymi celami Git są szybkość, integralność danych, obsługa rozproszonych, nieliniowych przepływów pracy. Git jest instalowany i obsługiwany na komputerze lokalnym zamiast w chmurze.

GitHub to oparta na chmurze usługa hostingu repozytorium Git, która łączy zespoły. Zapewnia graficzny graficzny interfejs użytkownika, a także kontrolę dostępu i wiele funkcji współpracy, podstawowe narzędzia do zarządzania zadaniami dla każdego projektu.

Ponadto GitHub jest oprogramowaniem typu open source, co oznacza, że ​​kod jest przechowywany na scentralizowanym serwerze i każdy może uzyskać do niego dostęp.

P # 16) Co to jest konflikt w Git i jak go rozwiązać?

Odpowiedź: Git ma funkcję automatycznego scalania, która samodzielnie obsługuje zatwierdzenia scalania, pod warunkiem, że zmiany kodu nastąpiły w różnych wierszach i różnych plikach.

Ale w przypadku rywalizacji o zatwierdzenie, w którym występują zmiany w tych samych wierszach kodu pliku lub plik został usunięty w jednej gałęzi, ale istnieje i zmodyfikowany w innej, Git nie jest w stanie automatycznie rozwiązać różnic, a tym samym wywołuje konflikt podczas łączenia.

W takich przypadkach potrzebna jest Twoja pomoc w podjęciu decyzji, który kod dołączyć, a który odrzucić podczas ostatecznego scalania.

Konflikt scalania może wystąpić podczas scalania gałęzi, zmiany bazy gałęzi lub wybierania najlepszego zatwierdzenia. Po wykryciu konfliktu Git podświetla obszar, w którym występuje konflikt i prosi o jego rozwiązanie. Po rozwiązaniu konfliktu możesz kontynuować scalanie.

Wykonaj poniższe czynności, aby rozwiązać konflikt scalania konkurencyjnych zmian linii:

1. Otwórz Git Bash (wiersz poleceń Git).
2. Posługiwać się Płyta CD polecenie, aby przejść do lokalnego repozytorium Git, w którym występuje konflikt scalania.
3. Użyj status git polecenie, aby wyświetlić listę plików, na które ma wpływ konflikt scalania.
4. Otwórz używany edytor tekstu i przejdź do pliku, w którym występują konflikty scalania.
5. Aby zobaczyć początek konfliktu scalania w pliku, poszukaj w dokumencie znacznika konfliktu<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> NAZWA ODDZIAŁU.
6. Wybierz w przypadku, gdy chcesz zachować tylko zmiany z gałęzi, po prostu zachowaj zmiany z drugiej gałęzi lub wprowadź nową zmianę, która może obejmować zmiany z dwóch gałęzi. Usuń znaczniki konfliktu<<<<<<>>>>>> i dokonaj zmian, których potrzebujesz w ostatecznym scaleniu.
7. Posługiwać się git dodaje. polecenie, aby dodać lub przygotować zmiany.
8. Na koniec użyj git commit -m „wiadomość” polecenie, aby zatwierdzić zmiany z komentarzem.

Aby rozwiązać usunięty konflikt scalania plików, musisz wykonać poniższe czynności:

1. Otwórz Git Bash (wiersz poleceń Git).
2. Posługiwać się Płyta CD polecenie, aby przejść do lokalnego repozytorium Git, w którym występuje konflikt scalania.
3. Użyj status git polecenie, aby wyświetlić listę plików, na które ma wpływ konflikt scalania.
4. Otwórz używany edytor tekstu i przejdź do pliku, w którym występują konflikty scalania.
5. Wybierz, czy chcesz zachować usunięty plik. Możesz sprawdzić najnowsze zmiany wprowadzone w usuniętym pliku w edytorze tekstu.
6. Posługiwać się git add polecenie, aby dodać usunięty plik z powrotem do repozytorium. Albo użyj idź rm polecenie usunięcia pliku z repozytorium.
7. Na koniec użyj git commit -m „wiadomość” polecenie, aby zatwierdzić zmiany z komentarzem.

P # 17) Jak naprawisz zepsute zobowiązanie?

Odpowiedź: Aby naprawić uszkodzony zatwierdzenie lub zmienić ostatnie zatwierdzenie, najwygodniejszą metodą jest użycie polecenia „ git commit -amend ” .

Pozwala łączyć zmiany etapowe z poprzednim zatwierdzeniem jako alternatywę dla tworzenia całkowicie nowego zatwierdzenia. Spowoduje to zastąpienie ostatniego zatwierdzenia zmienionym zatwierdzeniem.

(wizerunek źródło )

Za pomocą tego polecenia można również edytować poprzedni komunikat o zatwierdzeniu bez zmiany jego migawki.

P # 18) Jakie jest zastosowanie git instaweb?

Odpowiedź: Jest to skrypt, dzięki któremu możesz błyskawicznie przeglądać działające repozytorium Git w przeglądarce internetowej.

Ten skrypt konfiguruje gitweb i serwer WWW do przeglądania lokalnego repozytorium. Automatycznie kieruje przeglądarkę internetową i uruchamia serwer sieciowy przez interfejs do lokalnego repozytorium.

P # 19) Co to jest git is-tree?

Odpowiedź: „Git is-tree” oznacza obiekt drzewa zawierający tryb i nazwę wszystkich elementów wraz z wartością SHA-1 obiektu blob lub drzewa.

Pytanie # 20) Czy istnieje sposób, aby cofnąć zatwierdzenie git, które zostało już przesłane i upublicznione?

Odpowiedź: Tak, aby naprawić lub cofnąć złe zatwierdzenie, istnieją dwa podejścia, które można zastosować w zależności od scenariusza.

Oni są:

1. Bardzo oczywistym sposobem jest wykonanie nowego zatwierdzenia, w którym usuniesz zły plik lub naprawisz błędy w nim. Po zakończeniu możesz przesłać go do zdalnego repozytorium.
2. Innym podejściem jest utworzenie nowego zatwierdzenia, aby cofnąć wszystkie zmiany wprowadzone w poprzednim złym zatwierdzeniu. Można to zrobić za pomocą polecenia git revert - „ git revert '

Q # 21) Jak odróżnisz git pull od git fetch?

Odpowiedź: Git pull polecenie pobiera wszystkie nowe zatwierdzenia z określonej gałęzi w centralnym repozytorium i aktualizuje gałąź docelową w repozytorium lokalnym.

Pobieranie Git również zmierza do tego samego, jednak jego podstawowa funkcjonalność jest nieco inna. Kiedy wykonasz pobieranie git, wszystkie nowe zatwierdzenia z określonej gałęzi zostaną pobrane z twojego centralnego repozytorium, a te zmiany zostaną zapisane w nowej gałęzi w twoim lokalnym repozytorium. Nazywa się to pobraną gałęzią.

Jeśli chcesz zobaczyć te zmiany w swojej gałęzi docelowej, musisz wykonać połącz się po pobraniu git. Gałąź docelowa zostanie zaktualizowana o najnowsze zmiany dopiero po połączeniu jej z pobraną gałęzią.

Tak więc git pull aktualizuje lokalną gałąź o jej zdalną wersję, podczas gdy git fetch nie zmienia bezpośrednio twojego lokalnego oddziału lub kopii roboczej w refs / heads. Pobieranie Git może służyć do aktualizowania gałęzi zdalnego śledzenia w ramach refs / piloty //.

W prostych słowach git pull jest równe git fetch, po którym następuje git merge .

P # 22) Jakie jest zastosowanie obszaru przejściowego lub indeksowania w Git?

Odpowiedź: Z punktu widzenia Gita istnieją trzy obszary, w których można przechowywać zmiany w plikach, tj. Katalog roboczy, obszar przemieszczania i repozytorium.

Najpierw dokonujesz zmian w katalogu roboczym projektu przechowywanym w systemie plików komputera. Wszystkie zmiany pozostają tutaj, dopóki nie dodasz ich do obszaru pośredniego zwanego strefą przejściową.

Możesz zaplanować zmiany, wykonując git add. Komenda. Ten obszar pomostowy daje ci podgląd twojego następnego zatwierdzenia i zasadniczo pozwala ci dostroić twoje zatwierdzenia. Możesz dodawać lub usuwać zmiany w obszarze przejściowym, dopóki nie będziesz zadowolony z wersji, którą zamierzasz zatwierdzić.

Po zweryfikowaniu zmian i wypisaniu się ze zmienionego etapu możesz ostatecznie zatwierdzić zmiany. Po zatwierdzeniu trafiają do lokalnego repozytorium, tj. Do katalogu .git / objects.

Jeśli używasz Git GUI, zobaczysz opcję wprowadzenia zmian. Na poniższym zrzucie ekranu plik sample.txt znajduje się w obszarze zmian, co oznacza, że ​​znajduje się w katalogu roboczym.

Możesz wybrać plik i kliknąć „Zmieniono etap”, po czym zostanie on przeniesiony do obszaru przejściowego. Na przykład , plik hello.txt znajduje się w obszarze zmiany etapu (zostanie zatwierdzony). Możesz zweryfikować swoje zmiany, a następnie dokonać podpisu, a następnie zatwierdzić.

Staging jest również nazywany indeksowaniem, ponieważ git utrzymuje plik indeksu, aby śledzić zmiany pliku w tych trzech obszarach. Pliki, które są przemieszczane, znajdują się obecnie w Twoim indeksie.

Po dodaniu zmian do obszaru przemieszczania informacje w indeksie są aktualizowane. Kiedy robisz zatwierdzenie, zatwierdzane jest to, co jest w indeksie, a nie to, co jest w katalogu roboczym. Możesz użyć status git polecenie, aby zobaczyć, co jest w indeksie.

Pytanie # 23) Co to jest Git Stash?

Odpowiedź: Magazyn GIT przechwytuje bieżący stan katalogu roboczego i indeksu oraz przechowuje go na stosie do wykorzystania w przyszłości. Przywraca niezatwierdzone zmiany (zarówno przemieszczane, jak i niestazowane) z katalogu roboczego i zwraca czyste drzewo robocze.

Możesz teraz popracować nad czymś innym, a kiedy wrócisz, możesz ponownie zastosować te zmiany. Tak więc, jeśli chcesz przełączyć się z jednego kontekstu na inny bez utraty obecnych zmian, możesz użyć skrytki.

Jest to pomocne przy szybkim przełączaniu kontekstu, gdy jesteś w połowie zmiany kodu, której nie chcesz teraz zatwierdzać ani cofać i masz coś innego do zrobienia. Polecenie do użycia to git stash.

P # 24) Co to jest zrzut Git Stash?

Odpowiedź: Kiedy nie potrzebujesz już określonej skrytki, możesz ją usunąć, wykonując git stash drop polecenie . Jeśli chcesz usunąć wszystkie skrytki za jednym razem z repozytorium, możesz uruchomić polecenie git stash clear .

P # 25) Jakie zastosowanie ma magazyn Git? Czym różni się od Git Stash Pop?

Odpowiedź: Oba polecenia są używane do ponownego zastosowania przechowywanych zmian i rozpoczęcia pracy od miejsca, w którym zostałeś.

W git stash Apply polecenie, zmiany zostaną ponownie zastosowane do kopii roboczej i również zostaną zachowane w skrytce. Tego polecenia można użyć, gdy chcesz zastosować te same ukryte zmiany w wielu gałęziach.

W git stash pop polecenie, zmiany są usuwane ze schowka i ponownie stosowane w kopii roboczej.

P # 26) Jakie jest zastosowanie polecenia git clone?

Odpowiedź: Plik git clone polecenie tworzy kopię istniejącego centralnego repozytorium Git na komputerze lokalnym.

P # 27) Kiedy jest używane polecenie git config?

Odpowiedź: Plik git config polecenie służy do ustawiania opcji konfiguracyjnych dla instalacji Git.

Na przykład, po pobraniu Gita musisz użyć poniższych poleceń config, aby ustawić nazwę użytkownika i zatwierdzić adres e-mail w Git:

$ git config –global user.name „”

$ git config –global user.email „”

Tak więc, głównie takie rzeczy, jak zachowanie repozytorium, informacje o użytkowniku i preferencje można ustawić za pomocą tego polecenia.

P # 28) W jaki sposób zidentyfikujesz, czy gałąź jest już połączona w master?

Odpowiedź:

Wykonując poniższe polecenia, możesz poznać stan scalania gałęzi:

1. git branch - scalony master: Spowoduje to wyświetlenie wszystkich gałęzi, których nazwy zmieniono na główne.
2. gałąź git - scalono: Spowoduje to wyświetlenie wszystkich gałęzi, które zostały scalone w HEAD.
3. git branch - bez połączenia: Spowoduje to wyświetlenie wszystkich gałęzi, które nie zostały jeszcze połączone.

Domyślnie to polecenie informuje o stanie scalania tylko oddziałów lokalnych. Jeśli chcesz wiedzieć o stanie scalania oddziałów lokalnych i zdalnych, możesz użyć -do flaga. Jeśli chcesz sprawdzić tylko zdalne gałęzie, możesz użyć -r flaga.

Pytanie # 29) Co to są hooki w Git?

Odpowiedź: Git hooks to określone skrypty uruchamiane przez Git przed lub po zdarzeniu, takim jak zatwierdzanie, wypychanie, aktualizacja lub odbieranie. Folder „hooks” znajdziesz w katalogu .git w swoim lokalnym repozytorium. Znajdziesz tutaj wbudowane skrypty przed zatwierdzeniem, po zatwierdzeniu, przed wypychaniem, po wypychaniu.

Te skrypty są wykonywane lokalnie przed lub po wystąpieniu zdarzenia. Możesz również zmodyfikować te skrypty zgodnie ze swoimi potrzebami, a Git wykona skrypt, gdy wystąpi to konkretne zdarzenie.

P # 30) Jaki jest pożytek z widelca git? Czym różni się rozwidlanie od klonowania?

Odpowiedź: Rozwidlenie projektu oznacza utworzenie zdalnej kopii oryginalnego repozytorium po stronie serwera. Możesz zmienić nazwę tej kopii i zacząć tworzyć nowy projekt bez wpływu na oryginalny projekt. Rozwidlenie nie jest podstawową koncepcją Gita.

Operacja rozwidlenia jest używana przez przepływ pracy Git i ten pomysł istnieje dłużej w przypadku darmowego oprogramowania typu open source, takiego jak GitHub. Ogólnie rzecz biorąc, po rozwidleniu projektu rzadko będziesz ponownie wnosić wkład do projektu nadrzędnego.

Na przykład, OpenBSD to podobny do Uniksa system operacyjny typu open source, który został opracowany przez rozwidlenie NetBSD, który jest kolejnym systemem operacyjnym typu open source, podobnym do Uniksa.

Jednak w rozwidleniu istnieje bezpośrednie połączenie między twoją rozwidloną kopią a oryginalnym repozytorium. W dowolnym momencie możesz wnieść wkład z powrotem do oryginalnego projektu, używając żądań ściągnięcia.

W kopii rozwidlonej wszystkie główne dane, takie jak kody i pliki, są kopiowane z oryginalnego repozytorium, jednak gałęzie, żądania ściągnięcia i inne funkcje nie są kopiowane. Rozwidlenie to idealny sposób na współpracę typu open source.

Klonowanie jest zasadniczo koncepcją Gita. Klon to lokalna kopia dowolnego zdalnego repozytorium. Kiedy klonujemy repozytorium, całe repozytorium źródłowe wraz z historią i gałęziami jest kopiowane na nasz lokalny komputer.

W przeciwieństwie do rozwidlania, nie ma bezpośredniego połączenia między sklonowanym repozytorium a oryginalnym zdalnym repozytorium. Jeśli chcesz wykonywać żądania ściągnięcia i kontynuować powrót do oryginalnego projektu, powinieneś zostać dodany jako współpracownik w oryginalnym repozytorium.

Klonowanie to także świetny sposób na utworzenie kopii zapasowej oryginalnego repozytorium, ponieważ sklonowana kopia zawiera również całą historię zatwierdzeń.

Q # 31) Jak dowiesz się, jakie wszystkie pliki zostały zmienione w konkretnym zatwierdzeniu Git?

Odpowiedź: Korzystając z wartości skrótu określonego zatwierdzenia, możesz wykonać poniższe polecenie, aby uzyskać listę plików, które zostały zmienione w danym zatwierdzeniu:

git diff-tree -r {hash}

Spowoduje to wyświetlenie wszystkich plików, które zostały zmodyfikowane, a także plików, które zostały dodane. Flaga -r jest używana do wyświetlania listy pojedynczych plików wraz z ich ścieżkami zamiast zwijania ich tylko w nazwach ich katalogów głównych.

Możesz również użyć poniższego polecenia:

git diff-tree –no-commit-id –name-only -r {hash}

–No-commit-id ponownie przetrenuje wartości skrótu zatwierdzenia, które pojawią się na wyjściu. Natomiast -name wykluczy ścieżki do plików i poda tylko nazwy plików w danych wyjściowych.

Pytanie # 32) Jaka jest różnica między git checkout (nazwa gałęzi) a git checkout -b (nazwa gałęzi)?

Odpowiedź: Komenda git checkout (nazwa oddziału) przełączy się z jednej gałęzi na drugą.

Komenda git checkout -b (nazwa gałęzi) utworzy nową gałąź i również się do niej przełączy.

Q # 33) Co to jest SubGit?

Odpowiedź: SubGit to narzędzie używane do migracji SVN do Git. Jest rozwijany przez firmę o nazwie TMate. Konwertuje repozytoria SVN do Git i umożliwia jednoczesną pracę na obu systemach. Automatycznie synchronizuje SVN z Git.

(wizerunek źródło )

Możesz stworzyć kopię lustrzaną SVN || Git używając tego narzędzia. SubGit powinien być zainstalowany na serwerze Git. Wykryje wszystkie ustawienia zdalnego repozytorium SVN, w tym wersje SVN, gałęzie i tagi, i przekształci je w zatwierdzenia Git.

Zachowuje również historię, w tym śledzenie danych scalania.

P # 34) Czy możesz odzyskać usuniętą gałąź w Git?

Odpowiedź: Tak, możesz. Aby odzyskać usuniętą gałąź, powinieneś znać SHA z góry. SHA lub hash to unikalny identyfikator, który Git tworzy przy każdej operacji.

Kiedy usuniesz oddział, otrzymasz SHA wyświetlaną na terminalu:

Usunięty oddział (był)

Możesz użyć poniższego polecenia, aby odzyskać usuniętą gałąź:

git checkout -b

Jeśli nie znasz SHA dla zatwierdzenia na końcu swojej gałęzi, możesz najpierw użyć przejdź do reflog polecenie, aby poznać wartość SHA, a następnie zastosuj powyższe polecenie wypisania, aby przywrócić gałąź.

Q # 35) Co jest git diff Komenda? Czym to się różni od status gita?

Odpowiedź: Git diff jest poleceniem wielokrotnego użytku, które można wykonać, aby pokazać różnice między dwoma dowolnymi zatwierdzeniami, zmiany między drzewem roboczym a zatwierdzeniem, zmiany między drzewem roboczym a indeksem, zmiany między dwoma plikami, zmiany między indeksem a drzewem itp.

Plik status git polecenie służy do inspekcji repozytorium. Pokazuje stan katalogu roboczego i obszaru przemieszczania. Spowoduje to wyświetlenie plików, które zostały przemieszczone, które nie zostały przemieszczone, i pliki, które nie zostały prześledzone.

P # 36) Co zawiera obiekt Commit?

Odpowiedź: Obiekt zatwierdzenia zawiera hash obiektu drzewa najwyższego poziomu, hash zatwierdzeń nadrzędnych (jeśli istnieje), informacje o autorze i autorach, datę zatwierdzenia i komunikat o zatwierdzeniu.

Możesz to wyświetlić za pomocą git log Komenda.

Przykład:

(wizerunek źródło )

P # 37) Co to jest git cherry-pick? Jakie są scenariusze, w których można użyć git cherry-pick?

Odpowiedź: Git Cherry-Pick jest potężnym poleceniem do zastosowania zmian wprowadzonych przez jeden lub więcej istniejących zatwierdzeń. Pozwala wybrać zmianę z jednej gałęzi i zastosować ją w innej.

git cherry-pick commitSha to polecenie używane do zbierania wiśni. commitSha jest odniesieniem do zatwierdzenia.

Tego polecenia można użyć do cofnięcia zmian. Na przykład, jeśli przez pomyłkę dokonałeś zatwierdzenia do złej gałęzi, możesz sprawdzić poprawną gałąź i wybrać zatwierdzenie do miejsca, w którym powinno ono należeć.

Może być również używany we współpracy zespołowej. Mogą istnieć scenariusze, w których ten sam kod musi być współużytkowany między dwoma składnikami produktu. W takim przypadku, jeśli jeden programista już napisał ten kod, drugi może wybrać ten sam.

Zbieranie wiśni jest również przydatne w naprawach błędów, w których zatwierdzenie poprawki można wybrać bezpośrednio do gałęzi głównej, aby jak najszybciej naprawić problem.

P # 38) Do czego służy „git reset”? Jaki jest domyślny tryb tego polecenia?

Odpowiedź: Reset Gita to potężne polecenie do cofania lokalnych zmian stanu repozytorium Git. To polecenie resetuje bieżący HEAD do określonego etapu.

Resetuje zarówno indeks, jak i katalog roboczy do stanu ostatniego zatwierdzenia. Reset Gita ma trzy tryby, tj. Miękki, twardy i mieszany. Domyślny tryb pracy jest mieszany.

P # 39) Jaka jest różnica między „HEAD”, „drzewem roboczym” i „indeksem”?

Odpowiedź: Drzewo robocze lub obszar roboczy to katalog zawierający pliki źródłowe, nad którymi aktualnie pracujesz.

Indeks to obszar przemieszczania w Git, w którym przygotowywane są zatwierdzenia. Znajduje się pomiędzy zatwierdzeniem a twoim drzewem roboczym. Indeks Git to jeden duży plik binarny, który rejestruje wszystkie pliki w bieżącej gałęzi, ich nazwy, sumy kontrolne sha1 i znaczniki czasu.

Ten plik znajduje się w /.git/index. HEAD jest odniesieniem lub wskaźnikiem do ostatniego zatwierdzenia w bieżącej gałęzi pobierania.

P # 40) Jaka jest różnica między rebase a merge? Kiedy powinieneś zmienić bazę, a kiedy połączyć?

Odpowiedź: Zarówno polecenia rebase, jak i merge są używane do integrowania zmian z jednej gałęzi do drugiej, ale w inny sposób.

Jak widać na poniższych dwóch obrazkach, załóżmy, że masz zatwierdzenia (to jest przed scaleniem / rebase). Po scaleniu otrzymasz wynik jako kombinację zatwierdzeń. Łączy ze sobą historie obu gałęzi i tworzy nowe „zatwierdzenie scalające” w gałęzi cech.

Z drugiej strony rebase przesunie całą gałąź funkcji, aby rozpocząć na końcu gałęzi głównej.

(wizerunek źródło )

Commity będą wyglądać następująco:

Rebasing nie jest zalecany w przypadku oddziałów publicznych, ponieważ tworzy niespójne repozytoria. Jednak zmiana bazy jest dobrą opcją dla oddziałów prywatnych / indywidualnych programistów. Nie nadaje się do trybu rozgałęzienia na funkcję. Ale jeśli masz model rozgałęzienia na programistę, zmiana bazy nie jest szkodliwa.

Ponadto rebase jest operacją destrukcyjną, więc Twój zespół programistów powinien mieć wystarczające umiejętności, aby poprawnie ją zastosować. W przeciwnym razie można stracić zaangażowaną pracę.

Brute Force Password Cracker do pobrania dla Androida

Co więcej, cofnięcie scalenia jest łatwiejsze niż przywrócenie rebase. Tak więc, jeśli wiesz, że mogą być wymagane możliwości przywrócenia, powinieneś użyć scalania.

Merge utrzymuje historię taką, jaka jest, podczas gdy rebase przepisuje historię. Dlatego jeśli chcesz zobaczyć historię dokładnie tak, jak się pojawiła, powinieneś użyć scalania.

P # 41) Jaka jest składnia zmiany bazy?

Odpowiedź: Składnia polecenia rebase to git rebase (nowe-zatwierdzenie)

P # 42) W jaki sposób usuniesz plik z Git bez usuwania go z lokalnego systemu plików?

Odpowiedź: W tym celu możesz użyć opcji „buforowany”:

git rm -rf –cached $ FILES

To polecenie usunie pliki z repozytorium bez usuwania ich z dysku.

Pytanie # 43) Jaki jest typowy wzorzec rozgałęzień w Git?

Odpowiedź: Wspólny wzorzec rozgałęzień jest oparty na git-flow. Ma dwie główne gałęzie, tj. Master i development.

• Gałąź główna zawiera kod produkcji. Cały kod programistyczny jest w pewnym momencie scalany z gałęzią główną.
• Gałąź programistyczna zawiera kod przedprodukcyjny. Po zakończeniu funkcji są one scalane z gałęzią główną, zwykle za pośrednictwem potoku ciągłej integracji / ciągłej integracji.

Ten model ma również kilka gałęzi pomocniczych, które są wykorzystywane podczas cyklu rozwojowego:

• Gałęzie tematyczne / Branże tematyczne: Służą do opracowywania nowych funkcji dla przyszłych wydań. Może odgałęzić się od gałęzi develop i musi zostać z powrotem scalony z gałęzią develop. Ogólnie rzecz biorąc, te gałęzie istnieją tylko w repozytoriach programistów, a nie w źródle.
• Gałęzie poprawek: Są używane do nieplanowanego wydania produkcyjnego, gdy istnieje potrzeba natychmiastowej naprawy krytycznego błędu w wersji produkcyjnej na żywo. Mogą odgałęziać się od mastera i muszą zostać ponownie połączone w develop i master.
• Oddziały wydania: Służą do przygotowania nowej wersji produkcyjnej. Gałąź wydania umożliwia wprowadzenie drobnych poprawek błędów i przygotowanie metadanych do wydania. Mogą odejść od rozwoju i muszą zostać ponownie połączone w master i rozwijane.

Wniosek

Omówiliśmy ważne pytania, które są zwykle zadawane podczas wywiadów dotyczących Git w tym samouczku.

To nie tylko pomoże ci przygotować się do nadchodzących rozmów kwalifikacyjnych, ale także wyjaśni koncepcje git.

Życzę wszystkiego najlepszego podczas rozmowy kwalifikacyjnej!

rekomendowane lektury

• Pytania i odpowiedzi do wywiadu
• Kilka interesujących pytań do rozmowy kwalifikacyjnej dotyczącej testowania oprogramowania
• 40 najpopularniejszych pytań i odpowiedzi do wywiadów w zakresie programowania w języku C
• Top 40 popularnych pytań i odpowiedzi do wywiadów J2EE, które powinieneś przeczytać
• ETL Testing Interview Pytania i odpowiedzi
• Ponad 20 najczęściej zadawanych pytań i odpowiedzi na rozmowę kwalifikacyjną
• Najczęstsze pytania do wywiadów z Oracle Forms and Reports
• Niektóre trudne pytania i odpowiedzi do testowania ręcznego