Nie tak dawno pisałem o pracach nad wtyczką Social Connect, której rozwój wsparłem kilkoma swoimi pomysłami i poprawkami. Przy tej okazji miałem możliwość bardziej zapoznać się z GitHub’em, na którym do tej pory byłem jedynie zarejestrowany. Zbiegło się to mniej więcej z wydaniem wersji GitExtensions 2.10, która przyniosła możliwość integracji ze wspomnianym serwisem github.com – nie omieszkałem oczywiście wypróbować tego w praktyce. Konfiguracja ta nie jest czymś bardzo skomplikowanym, jednak może komuś przydać się tych kilka wskazówek.

Pomijam oczywiście tak oczywistą oczywistość jak zarejestrowanie konta w github.com (co jest niezbędne do dalszej integracji), załóżmy, że konto już posiadamy. Odpalamy zatem GitExtensions i korzystając z mało intuicyjnie umieszczonej opcji Plugins → Github (czytelniej byłoby umieścić to w dedykowanym podmenu Github) otwieramy okno jak poniżej:

O ile pola User i Password są oczywiste, o tyle APIToken może wywołać pewną konsternację u świeżo zarejestrowanych użytkowników. Z pomocą przychodzi jednak guzik „Get API Token”, po naciśnięciu którego trafiamy na stronę github.com, gdzie w ustawieniach swojego konta (w zakładce Account Admin) możemy odczytać potrzebny nam token:

Ostatnia opcja Preferred acces method aktywuje się w zależności od tego jak wypełnimy trzy pierwsze pola. Podanie hasła umożliwia łączenie zarówno przez ssh, jak i przez https, natomiast API token służy tylko i wyłącznie do komunikacji poprzez ssh.

Jeśli wybierzemy ssh, podamy i hasło, i token, to w momencie zatwierdzania zmian program wyświetli komunikat:

który ostrzega nas przed zbędnym trzymaniem hasła w rejestrze systemu. Klikając „nie” możemy wrócić do edycji ustawień i wyczyścić niepotrzebne hasło. Podobnie jest, gdy podamy jedynie login i hasło – aplikacja znowu nas ostrzeże:

Jak widać autor GitExtensions dba o bezpieczeństwo naszych danych uwierzytelniających, dlatego wprost informuje nas o tym, że hasło zapisane zostanie w dwóch niezbyt tajnych miejscach… Dlatego odradzam korzystanie z tego trybu, o wiele lepsze jest łączenie się poprzez ssh z użyciem tokenu API.

Niestety, o ile wybór trybu https jest najłatwiejszy pod względem konfiguracji (wystarczy podać login i hasło), o tyle połączenie po ssh niesie ze sobą kilka kolejnych uwarunkowań. Po pierwsze musimy mieć w systemie klienta dla protokołu ssh. GitExtensions wspiera zarówno Putty, jak i OpenSSH, ale z kolei GitHub obsługuje tylko to drugie, więc chcąc nie chcąc to właśnie OpenSSH musimy ustawić w opcjach:

Po drugie połączenie bez użycia hasła wymusza na nas użycie kluczy weryfikujących, które trzeba wygenerować u siebie, na urządzeniu, które wykorzystujemy do połączenia z GitHub’em oraz dodanie ich do swojego profilu.

Klucze publiczne autoryzowane do łączenia się z GitHub’em dodajemy w panelu:

Teoretycznie można swój klucz prywatny przenosić między urządzeniami i łączyć się zawsze używając tego samego. Dobrą praktyką jest jednak wygenerowanie innego klucza dla każdego z urządzeń, na których będziemy używać duetu GitExtensions – GitHub, w ten sposób w przypadku straty jednego z nich po prostu usuwamy klucz z listy autoryzowanych kluczy i nie musimy zmieniać konfiguracji w pozostałych urządzeniach. Oczywiście nikomu nie życzę takich sytuacji, niemniej jednak warto tak właśnie zrobić.

Aby dodać klucz należy wybrać opcję „Add another public key”. Pojawi nam się króciutki formularz:

w którym podajemy nazwę klucza (najlepiej taką, by kojarzyła się z urządzeniem, na którym z tego klucza będziemy korzystać) i jego zawartość, którą wcześniej wygenerowaliśmy.

Aby sprawdzić, czy wszystko skonfigurowaliśmy poprawnie wystarczy wejść w linię poleceń (w tym celu w GitExtensions klikamy ctrl+G, lub wybieramy w menu Git → Git Bash (oczywiście można też użyć Putty, Cygwin’a lub nawet standardowego wiersza poleceń Windows, ale nie ma co mieszać, bo notka jest o czym innym)) i wydać komendę:

Powyższa komenda jest jak najbardziej poprawna – nie należy zmieniać nazwy użytkownika. Zostaniemy rozpoznani mimo wszystko, dzięki podanemu loginowi lub dzięki kluczowi ssh. Nie należy spodziewać się pełnej sesji ssh, gdyż serwer GitHub’a nie oferuje dostępu do powłoki. Jedyne, co zobaczymy to monit o dodanie serwera do listy znanych adresów, czyli coś w stylu:

Oczywiście wpisujemy „yes”, po czym powinniśmy ujrzeć:

Jest to jak najbardziej prawidłowy komunikat, którym nie należy się przejmować. Połączenie zostało nawiązane, więc jest w porządku i można przejść do meritum – interakcji między GitExtensions, a GitHub’em.

Jest to tak naprawdę zestaw kilka użytecznych narzędzi do „forkowania”, klonowania i wyszukiwania repozytoriów. Jest też oczywiście podgląd repozytoriów połączonych z naszym kontem w github.com:

W przypadku repozytoriów założonych przez nas, w momencie klonowania tworzona jest lokalna kopia, a nasze repozytorium w github.com staje się automatycznie repozytorium zdalnym. Ciekawa sprawa jest w momencie klonowania repozytorium, które jest jedynie „forkowane” – poza lokalną kopią dodawane są dwa zdalne repozytoria: nasza instancja na serwerze GitHub oraz oryginalne repozytorium, z którego nasze zostało „sforkowane” (swoją drogą, istnieje polski odpowiednik tej czynności ;)?). Dzięki temu mamy zarówno możliwość prac nad swoją wersją aplikacji, jak i śledzenia postępów prac nad oryginałem. Tak jest w tym przypadku, gdy dla przykładu wykorzystałem wspomniane już repozytorium wtyczki Social Connect.

Po kliknięciu guzika „Clone” pojawi się okno z przebiegiem całego procesu, ostatecznie powinno wyglądać mniej więcej tak:

Zaraz po sklonowaniu nie widzimy niestety stanu zdalnego, oryginalnego repozytorium (w tym przypadku repo użytkownika thenbrent), wobec czego klikając ctrl+Dół (lub w menu Commands → Pull) zaciągamy potrzebne informacje:

Ważna jest tu opcja „Do not merge, only fetch remote branch” – niestety GitExtensions nie ma specjalnie wydzielonej opcji Fetch, co również może być lekko mylące dla początkowych użytkowników. Po tej operacji drzewko pokazuje już wszystko co powinno:

Widzimy zarówno naszą lokalną gałąź master, jak i gałęzie naszej zdalnej instancji oraz stan „oryginalnego” repozytorium.

Z poziomu GitExtensions teoretycznie można też tworzyć i podglądać pull requesty, czyli prośby wysyłane do autorów oryginalnych repozytoriów, by ci zapoznali się z naszymi zmianami, pomysłami… w praktyce jednak miałem z tym problem więc zostanie to do rozgryzienia na następny raz.