Visual Studio i git. Opis wbudowanego menadżera.

(English Version of this article – wersja angielska)

Jakiś czas temu próbowałem korzystać z Git przez provider dołączony do Visual Studio, wtedy nie byłem z niego zadowolony, zobaczę czy teraz narzędzia dołączone domyślnie do Visual Studio nadaje się do codziennego użytku.

Post dedykuje dotychczasowym użytkownikom TFSa, którzy muszą się przenieść na nowy system kontroli wersji. 🙂

Konfiguracja

Jeżeli do tej pory korzystaliśmy z TFSa musimy zmienić Source Control plugin, aby tego dokonać Przejdź przez Tools -> Options -> Source Control I zmienić Current source control plug-in na Git.

Nowe repozytorium

Jeżeli chcesz możesz przejść mały tutorial razem z tym postem.

Utwórz nowy projekt konsolowy File -> New -> Project...

(Trzeba zaznaczyć checkbox w czerwonym zaznaczeniu.)

Uwaga tak utworzone repozytorium nie już puste, posiada dwa commity (TFSowe Check-iny)! Oprócz wykonania polecenia równego z konsolowym git init dzieją się następujące rzeczy:

• Dodanie .gitignore i .gitattributes – pierwszy commit
• Pliki projektowe (.sln, .csproj, Program.cs, App.config, AssemblyInfo.cs) – drugi commit

.gitignore posiada listę rozszerzeń i folderów, które git nie powinien proponować do dodania jeżeli znajdują się w katalogu naszego repozytorium. .gitignore zazwyczaj jest przygotowany pod określone środowisko pracy, w naszym przypadku tym środowiskiem pracy jest Visual Studio. Bardzo przybliżoną wersję tego co znajduje się w tym pliku można zobaczyć na GitHubie.

.gitattributes między innymi, ustala jak git ma podchodzić do znaku końca linii (CRLF na Windows kontra LF an Linux).

Zawiera on linijkę * text=auto, która powoduje, że:

1. Git zgaduje czy plik jest plikiem tekstowym
2. Jeżeli jest plikiem tekstowym to: przy commitcie zamieni CRLF na LF i taki plik będzie trzymać w swojej bazie. Przy pobieraniu zmian, będzie pamiętać, że lubimy CRLF, bo pracujemy na Windows i zamieni nam plik końca linii na z LF na CRLF.

Team Explorer

Kiedy mamy otwartą solucje, która znajduje się pod kontrolą gita, możemy nim zarządzać poprzez Team Explorer (Ctrl+\  Ctrl+M). W porównaniu z TFS-em mamy mniej opcji do wyboru. Np. nie korzystamy z Source Control Explorer.

Opis zacznę od końca czyli od Settings.

Settings

Ustawienia możemy podzielić na globalne, które dotyczą wszystkich repozytoriów, z których korzystamy na tym komputerze oraz na ustawienia dotyczące tylko tego jednego repozytorium.

Global Settings

Nazwa użytkowania oraz email to wartości, którymi będziemy podpisywali się w naszych commitach.

Default Repository Location to ścieżka, która jest używana, na przykład, kiedy wywoła się File -> New -> Repository. Można to zignorować.

Commit changes after merge by default – Ustawia czy po połączeniu dwóch gałęzi (branches) ma być wykonywany automatyczny commit, podsumowujący zmiany. I tak musimy go zrobić, po prostu Git robi to automatycznie abyśmy mieli mniej pracy. Dla tych biegłych w konsolowym gitcie to ustawienie dodaje lub nie przełącznik --no-commit do git pull

Diff Tool określa jakiego narzędzia używamy do pokazania różnic między plikami dwoma plikami. Możemy ustawić Visual Studio, poprzez Use Visual Studio

Merge tool pokazuje różnice pomiędzy Remote (plik, który ściągamy) , Current (stan po merge) i Local (zmiany, które mamy lokalnie). Również możemy ustawić Visual Studio jako merge tool poprzez Use Visual Studio.

Ustawienia repozytorium

Możemy nadpisać ustawienia globalne dotyczące używanego „podpisu” do commita.

Mamy dostęp do plików .gitignore i .gitattributes z możliwością jej edycji.

Remotes to lista zewnętrznych serwerów, do których możemy wysłać (push) lub pobrać zmiany (fetch/pull) zmiany.

Nazwa origin jest zwyczajową nazwą dla domyślnego remote.

Sync

Przejdźmy do Home w Team Explorer, a następnie do Sync. W ten sposób możemy przesłać nasze dane do zewnętrznego serwera.

Pierwsze wysłanie danych na serwer jest trochę wyjątkowe, bo serwer nie wie jakie gałęzie mamy lokalnie. Dlatego nie może powiedzieć nam jakie różnice są między obecną gałęzią master, a zewnętrzną nie istniejącą gałęzią.

master to zwyczajowa nazwa dla głównej gałęzi w naszym repozytorium, nic nie stoi na przeszkodzie, aby ją usunąć i zastąpić inną. git nie dba o nazwy.

Musimy kliknąć na publish w celu wysłania informacji o lokalnych branchach i naszych 2 commitach, które zostały utworzone przez Visual Studio.

• Sync – wykonuje Pull i potem Push
• Fetch – pobiera commity z serwera
• Pull – wykonuje Fetch i automatycznie merge
• Push – wysyła twoje lokalne commity na serwer.

Changes

Kiedy wykonanamy jakieś zmiany w plikach, które są w repozytorium np. dodanie

Console.WriteLine("Hello, World");

do pliku Program.cs. Spowoduje, że na liście changes pojawi się plik Program.cs. Klikając na niego dwukrotnie możemy sprawdzić różnice, które wprowadziliśmy do pliku.

Po kliknięciu na Commit all dostaniemy informacje o tym, że commit został utworzony lokalnie

Aby inni deweloperzy mogli się cieszyć owocami naszej pracy musimy przesłać to na serwer.

Znów Sync

Tym razem Git już wie że ma śledzić zmiany na branchu master i mówi nam jakie commity są do wysłania.

Branches

Jest wiele praktyk tworzenia kodu przy użyciu Gita, jedną z najbardziej enterprise-owy model pracy to git flow. Dla jasności nie będę go tutaj całości opisywał, jednym z zaleceń jest tworzenie feature branchy. Mała lokalna gałąź tworzona na czas pracy nad pojedynczą funkcjonalnością.

Do zarządzania gałęziami przy użyciu Visual Studio służy panel Branches.

Mamy tutaj listę wszystkich lokalnych i zewnętrznych gałęzi używanych w naszym repozytorium. Kliknięcie prawym przyciskiem myszy na nazwę gałęzi, dostajemy kilka dodatkowych opcji co można zrobić z branchem.

• Checkout – to przełączenie na inną gałąź
• New Local Branch From... – utworzenie nowej gałęzi
• Merge From... – Połączenie dwóch gałęzi, podobnie do TFS-a
• Rebase Onto... – Połączenie dwóch gałęzi z innym wynikiem w historii. pl: Merge vs Rebase
• Reset – pozwala nam na wycofanie zmian nie za-commitowanych.

Utwórz nowy branch np. foo_feature.

Powtórzę, że zaznaczenie Checkout branch powoduje przełączenie się na nowy branch po jego stworzeniu.

Teraz wykonanie jakieś zmiany i jej za commitowanie, zostanie dodane do nowej gałęzi

Teraz, aby zmiany z gałęzi foo_feature znalazły się w gałęzi master, musimy wykonać merge.

Do wykonanie merge odbywa się w dwóch krokach:

1. Przełącz się na gałąź do której chcesz wciągnąć commity w naszym przypadku jest to master. Przełączyć się na inny branch możesz poprzez Branches i wykonując dwuklik na gałęzi.
2. Prawym przyciskiem myszy wybierz gałąź, która jest feature branchem i wybierz Merge From...

Powinien pojawić się dialog wyglądający tak.

Co nam zostało, to zatwierdzić przyciskiem Merge, aby dokonać połączenia dwóch gałęzi. No i pewnie chcemy, aby nasze zmiany były dostępne dla innych w tym celu znowu musimy udać się do Sync

Podsumowanie

Myślę, że da się używać tego narzędzia. Doskonałe do wykonywania podstawowych czynności.

Jednak nadal uważam, że znajomość konsoli, któregoś czarnego dnia się przyda, gdy wszystko zacznie się walić, a repozytorium palić.

Trzeba jeszcze zobaczyć jak plugin obsługuje przypadki, w których nie idzie wszystko gładko.