Opis jak zsynchronizować swoją kopię repozytorium, czyli fork, z głównym repozytorium na Github. Objaśnia jak zrobić, aby mieć najnowsze zmiany.

Pierwsze spotkanie z system kontroli wersji Git może być ciężkie z powodu domyślnie instalowanego edytora Vim. Moje pierwsze spotkanie z nim było pewnie takie same jak większości programistów, którzy wcześniej w Vimie nie pracowali. Nie umiałem z niego wyjść. Wpisałem git commit, moim oczom ukazał się jakiś edytor, próbowałem wpisać wiadomość, jednak coś nie działało. Chciałem opuścić ten tryb, jednak ESCAPE również nie działał. Co zrobić?

Jeśli pracujecie z kilkoma branchami, można czasami się trochę pogubić. Gdzie to skomitowaliśmy? Czy zrobiliśmy merge’a na odpowiedni branch? Aby porównać dwa branche można skorzystać z jakiejś aplikacji z GUI do obsługi gita np. SourceTree. Aplikacja ładnie wizualizuje nasze branche, jednak albo pokazuje jeden, albo wszystkie. Co zrobić jak chcemy porównać commity między dwoma konkretnymi branchami? Z pomocą przychodzi Nam polecenie git show-branch.

Wszystkie zmiany w kodzie, które robimy lokalnie w jakimś momencie musimy wrzucić do zdalnego repozytorium. Git nie pozwoli Nam wrzucić swoich zmian, jeśli nie mamy zsynchronizowanego repozytorium. Przed wrzuceniem naszej pracy musimy ściągnąć ostatnie commity wrzucone przez innych. Do ściągnięcia najnowszej wersji repozytorium służy polecenie git pull. W tym wpisie pokazać jak można zmienić zachowanie polecenia git pull i jakie to da korzyści.

Podstawy gita są bardzo proste. Aby zacząć korzystać z gita wystarczy znać tylko kilka poleceń. Jednak git jest potężnym narzędziem. Jeśli będziemy chcieli zrobić bardziej zaawansowane rzeczy możemy w pewnym momencie czuć się zagubieni. Możemy nawet bać się czegoś zrobić w obawie przed tym, że coś popsujemy. Warto najpierw przetestować różne polecenia bez obawy o utratę naszej pracy.

Pewnie nad tym się teraz zastanawiasz. Przecież commity się łączy w jeden, żeby historia była krótsza! Po co ją wydłużać? Po co w ogóle rozdzielać commit na dwa nowe? Jest kilka powodów: 1. Chcemy, żeby historia była bardziej czytelna. 2. Chcemy przeorganizować commity (interactive rebase) i powoduje Nam to konflikty. 3. Chcemy trzymać się zasady SRP (Single Responsibility Principle) w commitach, a do jednego wrzuciliśmy za dużo kodu. O tej zasadzie w kontekście gita przec...

Jak zacząłem korzystać z Gita to większość poleceń wykonywałem z linii poleceń. Visual Studio używałem tylko do rozwiązywania konfliktów. Jednak taki tryb pracy był trochę niewygodny. Gdy trzeba było rozwiązać konflikt, to:musiałem przełączyć się do Visual Studio (a przeważnie mam kilka programów otwartych, czasem trzeba trochę się nawciskać CTRL+TAB 🙂 ), teraz wpisuję jedną komendę i rozwiązuje konflikt w aplikacji kdiff3.