Fiszki Git

Sponsor kategorii

Git to rozproszony system kontroli wersji, stworzony przez Linusa Torvaldsa. Jest to narzędzie zaprojektowane z myślą o szybkości, integralności danych i wsparciu dla rozproszonych, nieliniowych przepływów pracy. Git charakteryzuje się elastycznością i wydajnością, umożliwiając efektywne zarządzanie zarówno małymi, jak i dużymi projektami programistycznymi. System ten oferuje zaawansowane funkcje branching'u i merging'u, zapewniając programistom narzędzia do sprawnej współpracy, śledzenia zmian i zarządzania kodem źródłowym. Git wspiera również pracę offline i szybkie przełączanie między wersjami projektu, zachowując przy tym niezawodność i umożliwiając łatwe odtworzenie historii zmian.

Nasza aplikacja z fiszkami zawiera starannie dobrane pytania rekrutacyjne z Gita wraz z wyczerpującymi odpowiedziami, które skutecznie przygotują Cię do każdej rozmowy kwalifikacyjnej wymagającej znajomości Git. IT Flashcards to nie tylko narzędzie dla osób szukających pracy - to doskonały sposób na utrwalanie i testowanie swojej wiedzy, niezależnie od Twoich aktualnych planów zawodowych. Regularne korzystanie z aplikacji pomoże Ci być na bieżąco z najnowszymi trendami z Git i utrzymać swoje umiejętności na wysokim poziomie.

Przykładowe fiszki Git z naszej aplikacji

Pobierz naszą aplikację w App Store lub Google Play, aby uzyskać więcej darmowych fiszek lub subskrybuj dostęp do wszystkich fiszek.

Co to jest "branch" w Git i jak można go użyć w procesie tworzenia oprogramowania?

Branch, zwany też gałęzią, w Git jest to niezależna linia rozwoju projektu. Tworzy się go, kiedy chcemy pracować nad nowymi funkcjonalnościami lub naprawą błędów, nie ingerując w główną linię rozwoju (master branch). Branching pozwala na prowadzenie wielu różnych wersji projektu jednocześnie, co jest efektywne, jeśli w jednym projekcie pracuje wielu programistów.

Podstawowym zastosowaniem branchy w procesie tworzenia oprogramowania jest sekwencja: tworzenie nowego brancha, dodawanie zmian, commitowanie zmian, a następnie scalanie tych zmian z głównym branchem.

Poniższy przykład pokazuje podstawowe operacje, które możemy wykonać na branchach.

# Tworzenie nowego brancha
git branch new_feature

# Przełączanie się pomiędzy branchami
git checkout new_feature

# Dodawanie zmian do brancha
# (...) wykonaj jakieś zmiany w plikach
git add .
git commit -m "Nowa funkcjonalność dodana"

# Wróc do mastera i scal zmiany z brancha new_feature
git checkout master
git merge new_feature

# Usuń branch po zakończeniu pracy
git branch -d new_feature

Dzięki branchom w Git mamy możliwość prowadzenia niezależnej pracy nad różnymi częściami projektu, które następnie możemy złączyć w dowolnym momencie.

Opisz różnicę między poleceniami git merge i git rebase.

Komenda git merge jest używana do połączenia dwóch lub więcej gałęzi w projekcie. Kiedy wykonujesz git merge, Git tworzy nowy commit, który zawiera zmiany z obu gałęzi. Zaletą git merge jest to, że historia projektu jest zachowana w takim stanie, w jakim była. Wszystko tworzy chronologiczną ścieżkę wydarzeń, dzięki której łatwiej zrozumieć, co się wydarzyło.

Z drugiej strony, git rebase jest używany do przenoszenia lub "aplikowania" serii commitów na nową bazę. Jest to używane, gdy chcesz utrzymać liniowy historyczny wykres projektu. Gdy wykonasz git rebase, Git 'przekleja' twoje zmiany na szczyt wybranej gałęzi. Możemy powiedzieć, że git rebase w pewien sposób 'czyści' historię commitów, co może prowadzić do utraty kontekstu, jeżeli merge/conflict jest źle zrozumiany i źle rozwiązany.

Zasadniczo, używa się git merge, żeby połączyć gałęzie i zachować historyczną ścieżkę projektu, natomiast git rebase pozwala na utrzymanie czystego, liniowego wykresu projektu, jednak kosztem utraty kontekstu. Obie metody mają swoje plusy i minusy, wybór zależy głównie od konkretnej sytuacji.

Co to jest "detached HEAD" i jak można do niego dojść podczas pracy z Git?

"Detached HEAD" to stan, w którym HEAD w Git nie jest podłączony do żadnej konkretnej gałęzi. Można to porównać do sytuacji, w której nasze zmiany nie są zapisywane na żadnej konkretnej gałęzi.

Do stanu "detached HEAD" można dojść na kilka różnych sposobów. Najczęściej zdarza się to podczas checkout'u do innego commit'a, np:

git checkout <commit_id>

Jednak ten stan możemy również osiągnąć podczas operacji takich jak rebase lub cherry-pick, które nie udały się pomyślnie.

Git wskazuje na ten stan za pomocą komunikatu:

Note: checking out 'commit_id'.
You are in 'detached HEAD' state.

"Detached HEAD" nie jest stanem niebezpiecznym, jest to naturalna część pracy z Gitem. Ważne jest jednak, aby przed przejściem do innego commit'a lub gałęzi zapisać swoje zmiany, które zrobiliśmy będąc w stanie "detached HEAD". Możemy to zrobić tworząc nową gałąź, której źródłem będzie nasz "detached HEAD". Zrobimy to poleceniem:

git branch new_branch_name

W jaki sposób można przenieść ostatnie commity z jednego brancha do innego?

Aby przenieść ostatnie commity z jednego brancha do innego, można użyć komendy `git cherry-pick`. Cherry picking w kontekście GIT-a oznacza wybieranie arbitralnego commita z jednej gałęzi i zastosowanie go do innej.

Pierwszym krokiem jest przejście na branch, z którego chcemy przenieść commity (nazwijmy go branchA):

git checkout branchA

Następnie, musimy zidentyfikować hash commitów, które chcemy przenieść. Możemy to zrobić używając komendy `git log`, która wyświetli listę commitów dla tego brancha. Hash commita to długi ciąg znaków na początku każdego wpisu commita.

Potem przechodzimy na branch, na który chcemy przenieść commity (nazwijmy go branchB):

git checkout branchB

Na koniec używamy polecenia `git cherry-pick` wraz z hashem commita, który chcemy przenieść:

git cherry-pick commit-hash

Jeśli chcemy przenieść kilka commitów, możemy podać ich hashe jeden po drugim, oddzielone spacją.