Praca z Gitem. Nie tylko okienka, nie tylko konsola.

P

Słowem wstępu

Praca z Gitem. Dużo się o nim mówi, zwłaszcza w środowisku .NET, głównie ze względu na to iż Microsoft kupił Github, a także udostępnił źródła .NET Standard i .NET Core na licencji Open Source (MIT). Osobiście, ciągle się uczę Gita i przy okazji sprawdzam, testuję różne rozwiązania około-gitowe. Wtyczki, narzędzia, różnego rodzaju integracje z Gitem. To sprawia, że wiem co mogę i ile mogę. Gita świetnie się obsługuje z poziomu konsoli czy terminala i przy tym pozostanę, ale zawsze dobrze mieć coś w zanadrzu.

 

Zamysł

Ludzie są różni i różne potrzeby mają. Ha! Taki komunał na początek.

Dlatego nie każdy będzie używać konsoli do pracy z Gitem. Osobiście uważam że jest to najlepsza droga ku temu, ale hej…każdy lubi „po swojemu”.

Do tematu podszedłem od strony czysto użytkowej. Git jest wspaniały ale, jak ze wszystkim, nie dla każdego. Owszem, da się, ale czy to oznacza, że od razu trzeba? Dlatego filozofie nt. tego czy trzeba czy nie, zostawiam na inny post, inny czas, inne…cokolwiek.

Poruszam ten temat jako programista i praca programistów właśnie, będzie na tapecie.

Kolejna porcja kolejnych oczywistości:

  • Wszyscy piszemy w jakimś języku i różne pliki posiadamy/wersjonujemy
  • Wszyscy używamy jakiegoś środowiska pracy
  • Wszyscy używamy jakiegoś systemu operacyjnego
  • Jedni wolą klikać myszką inni od niej stronią

 

Po kolei

Jeśli chodzi o języki programowania, to tak na prawdę nie ma znaczenia w jakim języku programujesz. Nie ma znaczenia czy wolisz back-end czy front-end. Git „przyjmie wszystko”.

Oczywiście jakieś binarki czy pliki graficzne będą problematyczne o tyle, że będzie je trudno odczytać, dla nas. Zrobiłem w tym celu mały eksperyment:

  • Inicjalizuję repozytorium lokalnie
  • Dogrywam zdjęcie
  • Commituję

 

  • Modyfikuję zdjęcie w gimpie

 

  • Podglądam zmiany w kliencie graficznym do gita

 

Jak widać, oglądanie jakichkolwiek plików binarnych, może być kłopotliwe. O ile ze zdjęciami może być w miarę bezproblemowo, jeśli mamy jakiś edytor graficzny, lub przeglądarkę i możemy do niego szybko załadować zdjęcie, o tyle z jakimkolwiek plikiem „uruchomieniowym” będzie problem.

 

Środowisko

Z punktu widzenia Gita, znowu, nie ma znaczenia jakiego IDE używasz.  W tej kwestii znaczenie jedynie może mieć jak bardzo Twoje środowisko jest „zgrane” z systemem kontroli wersji, często nie tylko z Gitem.

 

Visual Studio i Visual Studio Code

Przykładowo Visual Studio, od wersji Visual Studio 2013 Update 1, posiada klienta Git, wbudowanego bezpośrednio w IDE, umożliwiającego wykonanie wszystkich potrzebnych operacji (mniej zaawansowanych).

Tak samo Visual Studio Code. Potrafi pokazać zmiany na plikach za sprawą rozszerzeń które można dodać do tego IDE.

 

Rider

Środowisko Rider, od JetBrains, również posiada integrację z systemami kontroli wersji, w tym z Gitem.  Możliwości są całkiem spore:

  • Zarządzania gałęziami
  • Zarządzanie plikami z poziomu Solution Explorer
  • Zarządzanie plikami z poziomu samego pliku
  • Możliwość porównania rewizji
  • Możliwość przeglądania „drzewa zmian”
  • To nie wszystko…

Opcji i możliwości integracji z różnymi systemami kontroli wersji, JetBrains Rider ma na prawdę sporo. Z resztą, można się było tego spodziewać.

 

WebStorm

Możliwości środowiska WebStorm (również ze stajni JetBrains) wyglądają podobnie.

 

Eclipse

Środowisko Eclipse, jak pewnie się domyślasz, posiada odpowiednie plug-iny realizujące funkcjonalność integracji z systemem kontroli wersji, m.in. z Gitem. Jak to z Eclipse już jest, na prostych funkcjach się nie kończy. Można, nie tylko realizować commity i pushe itp. ale ogólnie zarządzać repozytorium, tak jakbyśmy mieli do czynienia z pełnoprawnym klientem Gita. To IDE jest mi zupełnie obce, dlatego ograniczę się tylko do wspomnienia o nim.

 

Vim

Tak samo jeśli chodzi o edytor Vim. Używasz Vima i uważasz, że duże, ciężkie środowiska to nie dla Ciebie? Nie ma problemu, Vim oczywiście też się potrafi zintegrować z Gitem

Wiele z wtyczek, skryptów nie jest już rozwijanych, ale jestem przekonany, że amator Vima znajdzie coś dla siebie: Lista

Za sprawą skryptu vcscommand.vim można korzystać z integracji z innymi systemami kontroli wersji.

 

Android Studio

Android Studio? Nie ma problemu. Nie dość, że ma wbudowaną podstawową integrację z Gitem, to jeszcze na dodatek można wygodnie zarządzać repozytorium, a także natywnie, obsługuje Githuba i Bitbucketa.

 

Dzisiaj trudno jest znaleźć środowisko programistyczne które nie obsługuje Gita, lub nie ma jakiegoś „pobocznego” sposobu na to, aby tego Gita obsługiwało. Ewidentnie popularność Gita jest jego mocną stroną.

 

System

Kolejnym elementem do rozpatrzenia, w kontekście Gita, jest system operacyjny. Wiadomo jak to jest, każdy ma inne potrzeby i inny rozmiar buta. Stare, dobrze ułożone na stopie buty, niechętnie się zmienia. Dlatego dobrze by było, aby można było korzystać z mocy Gita, niezależnie od OSa na jakim pracujesz. W zasadzie tak właśnie jest.

Dostępne są wersje na najpopularniejsze Windows, Mac, Linux, czy nawet na Androida i iOS. Nawet na FreeBSD. Choć można zauważyć pewne różnice w funkcjonowaniu Gita, pomiędzy różnymi systemami…np. w przypadku Windowsa jest odrobinę wolniejszy (dajmy na to generowanie blame’a) dla dużych plików lub dużych repozytoriów, jednakże wynika to raczej z „winy” systemu operacyjnego, nie samego Gita. Git jako taki, jest w pełni funkcjonalny i responsywny.

 

Klient Gita

Kolejna rzecz. Jeśli używasz Gita na zasadzie add – commit – push, lub po prostu nie chcesz się wyposażać w wiedzę nt. konsoli Gita, istnieje wiele prostych narzędzi pomagających w pracy z Gitem. Będziesz mógł/mogła „wyklikać” to czego oczekujesz.

Używałem trzech:

Moim zdaniem, najbardziej wygodny i posiadający najmniej „przeszkadzajek” jest Fork.

 

Natomiast jeśli kładziesz duży nacisk na pracę z kontrolą wersji, chcesz żeby była jeszcze szybsza i zależy Ci na dodatkowym skillu, prawdopodobnie użyjesz Git Bash, lub obsłużysz go z poziomu terminala czy PowerShella. Jest to metoda którą sam preferuję i polecam. Jest dla mnie coraz szybsza i przyjemniejsza. Jednakże, nie byłbym z Tobą szczery gdybym powiedział, że od tej metody pracy z Gitem zaczynałem. O nie. Pomimo doświadczenia w pracy z Mercurialem, nie rzuciłem się od razu na głęboką wodę, a może właśnie przez to… HgWorkbench to dobre narzędzie. Może dlatego szukałem jakiegoś UI-owego klienta Gita. Jedno jest pewne – jeśli nie miałeś/aś do czynienia z jakimkolwiek rozproszonym systemem kontroli wersji, tego typu narzędzia pozwolą Ci się z nim oswoić. Proponuję używać konsoli i jakiegoś wizualnego klienta jednocześnie. Uczyć się pracy z konsoli i sprawdzać na jakimś interfejsie rezultaty. Szybko się zorientujesz, że po jakiejś akcji z poziomu konsoli, nie zaglądasz „do UI” upewnić się co tam słychać.

Jeśli pracujesz „na Windowsie” i używasz PowerShella polecam dodatek (skrypt) – „posh-git” – o którym pisałem w poście „Aby PowerShell był bardziej power – dodatki i moduły do PowerShell„.

Dodatkowo, niezależnie od systemu można jeszcze bardziej przyspieszyć pracę aliasami, o których pisałem w poście „Git aliasy„.

 

Podsumowawszy

Prawdę powiedziawszy, te wszystkie dodatki, nakładki, wtyczki i dodatkowe moce nie są Ci do niczego potrzebne. Takie jest moje zdanie, ale tak jak już wspomniałem – „każdy lubi po swojemu”. Niezależnie od tego w jaki sposób, Ty i Twój zespół, będziecie pracować z kontrolą wersji, Git jest tego wart, a inwestycja w jego naukę szybko się zwraca.

 

A Ty? Jak używasz Gita? Używasz w ogóle? Napisz w komentarzach, co sądzisz. Napisz o jakimś ciekawym narzędziu o którym nie wspomniałem.

Znalazłeś błąd? Też napisz. A co!?

Zachęcam również do zasubskrybowania mojego newslettera. Dzięki temu, będziesz na bieżąco!

Czołem!

 



About the author

6 komentarzy

  • Hej, ja dorzucił bym od siebie narzędzie Tortiose Git (https://tortoisegit.org/), może trochę oldschoolowe, ale działam z nim na codzień dla projektów umieszczonych w repozytoriach Bitbucket Atlassiana. Dodaje to menu kontekstowe na plikach i folderach i włatwy sposób można zrobić praktycznie wszystko. Obsługuje wszystkie popularne skróty do działania z GITem. Do działania z GitHubem jest przyjazny GitHub Desktop (https://desktop.github.com/) na wszystkie platformy stworzony przez samego GitHuba.

  • Ja używam do większości rzeczy konsoli, do rozwiązywania konfliktów używam kdiff3. Visual Studio w ogóle nie używam do obsługi gita.

    Jak zaczynałem uczyć się gita to od razu chciałem się nauczyć poleceń i używać konsoli, chciałem wiedzieć jak ten Git działa od środka. Nie chciałem się uzależnić od jakiegoś klienta Gita.

    Do drobnej pomocy mam zainstalowany SourceTree, z którego czasami korzystam jak wiem, że tą rzecz akurat w SourceTree uda mi się szybciej zrobić.

    • Właśnie o to chodzi. Konsola i jakieś wspomagacze, od czasu do czasu. Wtedy praca jest szybka i bezproblemowa, po prostu „dzieje się”. Masz jakiś konkretny powód do używania kdiff3?

  • Jeżeli chodzi o gita i programowanie to mam podejście commit driven development, zakładam co ma moja praca zmienić w kodzie (tak w myśl zasady SRP) i później staram się to tak zakomitować, oczywiście czasami wychodzi więcej zmian niż planowałem, dlatego na etapie stagowania wybieram dokładnie które zmiany mają trafić do danego komita, często staguje poszczególne chunki albo linijki kodu. Dodatkowo staram się aby historia w gicie była jak najbardziej przejrzysta, traktuje ją na równi z kodem, który też powinien być dobrze sformatowany, aby był czytelny.

    Do obsługi gita podchodzę hybrydowo, z jednej strony GUI do wizualizacji z drugiej konsola do bardziej zaawansowanych rzeczy.
    GUI do gita ma służyć głównie do wizualizacji. Łatwiej jest zapanować nad całym drzewkiem komitów i nie pozwolić aby to drzewko zaczęło się krzaczyć (łatwiej jest podjąć decyzję czy mergować z fast-forward czy merge komitem, albo rebase), do tego w git GUI łatwiej przeglądać zmiany w kodzie, i co najważniejszcze zmiany można stageować po linijce w bardzo łatwy i intuicyjny sposób, co jest trochę trudniejsze do osiągnięcia z konsoli. Do tego takie GUI oferuje na tyle funkcjonalności, że większość podstawowych operacji można z niego przeprowadzić.
    Konsola przydaje się do wklepania bardziej skomplikowanych poleceń, ewentualnie do wykonania podstawowych komend jeżeli GUI zamula, albo akurat mamy odpaloną konsolę.
    Jeżeli chodzi o narzędzie do rozwiązywania konfliktów u mnie sprawdza się Visual Studio, które jest w stanie w miarę sprawne rozwiązywać konflikty do tego pozwala na edycję kodu w trakcie rozwiązywania konfliktu, a do tego VS zawsze gdzieś mam odpalone. Alternatywnie korzystam z małego onlinowego narzędzia do rozwiązywania konfliktów http://www.mergely.com/editor , ale wtedy kiedy mi zależy na rozwiązaniu konfliktów opartych o różnicę w plikach. Przydaje się np. wtedy kiedy ktoś zmieni formatowanie kodu w pliku i zmianach widać że cały plik został zmieniony, zamiast kilku linijek.

    Co do plików binarnych to git pozwala na ustawienie dowolnego programu do porównywania plików (per rozszerzenie), więc nie jest tak źle. Część git gui też jest w stanie wyświetlić pliki graficzne. Kiedyś korzystałem z Pandoc do porównywania zmian w pliku .docx https://github.com/vigente/gerardus/wiki/Integrate-git-diffs-with-word-docx-files

By Patryk

Autor serwisu

Patryk

Społecznościowe

Instagram

Newsletter



Historycznie

Tagi