Jak wytłumaczyć w prosty sposób czym są moduły w oprogramowaniu? Tworząc prezentację na Kariera IT wpadłem na ciekawe porównanie modułów  do działów firmy. W prosty sposób wyjaśnia to ten trudny koncept, dając jasny pogląd co jest ważne i dozwolone.

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.

Czasem zdarza mi się, że dodam do projektu jakiś plik i zanim wrzucę go do repozytorium, to on jednak okazuje się niepotrzebny. Do tej pory usuwałem ten plik ręcznie, albo w Eksploratorze Windows albo wpisując komendę: rm <ścieżka do pliku>, gdzie z racji tego, że projekt jest spory, to ścieżka do pliku zawiera w sobie kilka folderów. Jest jednak lepsze rozwiązanie.

W poprzednim poście pokazałem jak automatycznie dodawać numer zadania z VSTS do commit message. Dziś pokażę jak automatycznie dodać ten numer zadania do wielu ostatnich commitów. Z pomocą przychodzi Nam polecenie git filter-branch. Polecenie to zastosuje odpowiedni filtr (wybrany przez Nas) do każdego commita w branchu  i w efekcie powstanie nowy commit. Składnia dla tego polecenia składa się z 4 elementów:Podstawowe polecenie: git filter-branch.Nazwa filtru np.: --msg-filter.Pol...