Narzędzia

Co mi się nie podoba w obsłudze Gita w Visual studio

O gicie mówiono już wiele. O konsoli też. O Visual Studio z tego wszystkiego chyba najwięcej.

Na wstępie chciałbym powiedzieć, że jestem fanem konsoli, więc jeśli Ty nie jesteś, jesteś zadowolony z Visual Studio, to dalej możesz nie czytać. Choć z drugiej strony wpis będzie krótki.

Visual Studio już od długiego czasu potrafi sobie radzić z Gitem z wnętrza samego siebie. Najpierw był Git plugin. A od dość niedawna Git wspierany jest natywnie. Co to oznacza dla normalnego użytkownika? To że teraz commity, pushe, pulle, fetche i nawet rebase może robić z poziomu VS. Szybki przegląd jest tu.

Ale niestety – to nie działa jak należy. Są ku temu 3 powody:

  1. Robili to goście od TFS;
  2. Robili to jak na TFS przystało;
  3. Chyba zapomnieli, że to nie TFS;

Panowie mieli super podejście. Typowo Microsoftowe -> dajmy im tyle możliwości, ile naszym zdaniem wystarczy. Jak dostaną za dużo to będą kłopoty.

Właściwie założenie jest takie, że mimo, że system jest zdecentralizowany, to wygląda jakby z założenia projektantów jednak tak nie było. Świadczą o tym commit & push, commit & sync. Wiem, to fajna pomoc itd. Super, nie trzeba przyciskać 2 przycisków etc. Ale to też w pewnym sensie zwalnia od myślenia. Przyspiesza proces robienia głupot. Zamiast robić wiele commitów, zbierać je, a potem paczką wysłać na serwer jak wszystko będzie gotowe, mogę jak w TFS, wypychać jedna po drugiej.

Wyszukiwanie zmian po katalogach – odświeżanie Team Explorer. Nie wiem do końca jak to robi Visual Studio, ale on naprawdę wolno działa. Owszem jest świetny w rozwiązywaniu konfliktów. Owszem jest super w innych rzeczach (w sumie to w jednej – ma Resharpera i na tym dla mnie lista się kończy). Owszem to co mówisz teraz pod nosem też. Ale tak naprawdę Git w nim działa do kitu. Czasami wysłanie zmian potrafi trwać 20-30 sekund. Nie wiem co on robi w tym czasie.

No i gwóźdź do trumny. Brak wsparcia dla wielu elementów Gita. Nie wiem w pełni czego brakuje, ale bisecta to ja tam nie znalazłem. A to przecież “Key Feature” Gita. Zamiast szukać w kodzie co jest nie tak, przeszukujemy szybko źródła w systemie kontroli wersji uruchamiając bisecta i podając mu pod nos test, który sprawdza czy jest ok czy nie. Idziemy na herbatkę/kawkę/piwko/cokolwiek i po powrocie mamy wynik. W tym momencie błąd zaczął występować i prawdopodobnie tu należy szukać przyczyny problemów. Tylko dlatego walczyłem o wprowadzenie Gita w firmie w której pracuję. Ale ponieważ tam nie lubi się konsoli… TFS tego nie miał więc i tu zabrakło.

Na koniec dwie rzeczy: dobra i zła. Dobra to taka, że Visual potrafi przyznać się do niewiedzy (a nie każdy potrafi) i czasem nam oznajmia “Tego nie potrafię, dokończ czynność w konsoli” – super! A zła to taka, że jak działa się z konsoli to przeładowywanie projektu boli 🙂 Rym niezamierzony. Mnie Visual Studio potrafił się wyłożyć nieoczekiwanie lub spowodować inne problemy podczas przełączania brancha na poziomie konsoli. Zresztą po przełączeniu z poziomu Visuala było podobnie.

 

 

Git w konsoli działa super 🙂

5 thoughts on “Co mi się nie podoba w obsłudze Gita w Visual studio”

  1. Pingback: dotnetomaniak.pl
    1. Ja też, ale to słabe jest, że trzeba tak robić. Swoją drogą jak to nie jest VS tylko np Vim, to nie ma problemu w ogóle go wyłączyć, a potem włączyć, bo trwa to bardzo krótko. W VS to tak nie działa.

    1. Chyba ich nie używam i nie zauważyłem problemu. W sensie nie używam VS wcale prawie ostatnio.

Leave a Reply

Your email address will not be published. Required fields are marked *