Podstawowe opcje, takie jak ustawienie edytora, adresu e-mail, czy nazwy użytkownika definiuje praktycznie każdy. Zazwyczaj robimy to zaraz po instalacji Gita i później rzadko wracamy do tych ustawień. Jednak pracę z Gitem można usprawnić, korzystając z nieco mniej popularnych opcji konfiguracyjnych. W tym artykule pokażę Ci kilka z nich.

Konfiguracja warunkowa

Git umożliwia ustawienie różnych wartości dla wskazanych opcji konfiguracyjnych w określonych warunkach. Zwykle decydować będzie o tym lokalizacja projektu, ale może to być również konfiguracja specyficzna dla określonej gałęzi.

Dość powszechną sytuacją, gdzie ten mechanizm ma zastosowanie, jest praca nad projektami dla różnych podmiotów na jednej maszynie. W takiej sytuacji chcielibyśmy, by np. commity z projektów prywatnych były powiązane z prywatnym mailem, a te służbowe ze służbowym.

Możemy też chcieć dostosować się do specyficznych wymagań danego projektu np. wymogu merge bez trybu fast-forward.

Do warunkowej konfiguracji Gita służy klauzula includeIf. Klauzula includeIf pozwala warunkowo uwzględniać wybrane pliki konfiguracyjne, w zależności od kontekstu. By zaimplementować przykład z podziałem projektów na prywatne i służbowe należy utworzyć dodatkowe pliki konfiguracyjne. Załóżmy, że obecna maszyna to komputer służbowy, który można wykorzystywać do celów prywatnych. W takiej sytuacji wystarczy nam jeden dodatkowy plik z konfiguracją dla projektów prywatnych np. .gitconfig-personal. W tym pliku definiujemy opcje konfiguracyjne, które mają zostać nadpisane. Następnie w globalnej konfiguracji Gita definiujemy warunek, kiedy wskazany plik ma zostać dołączony oraz podajemy jego lokalizację.

[includeIf "gitdir:~/Projects/Personal/"]
    path = ~/path/to/.gitconfig-personal

Zwróć uwagę na slash (/) na końcu ścieżki. Git dzięki niemu rekursywnie użyje wskazanej konfiguracji dla wszystkich projektów w katalogu Personal.

W analogiczny sposób do gitdir działa słowo kluczowe onbranch pozwalające na dołączenie dodatkowej konfiguracji bazując na nazwie gałęzi.

Autokorekta

Jednym z błędów, który notorycznie popełniam pracując z Gitem, są literówki. Nie zliczę, ile razy wpisałem git chcekout czy git comit. Na szczęście Git posiada mechanizm autokorekty. Dzięki temu możemy wywołać polecenie rozpoznane przez Gita. Będzie to zwykle szybsze niż poprawianie czy pisanie od nowa niepoprawnego polecenia.

Jeśli popełnimy literówkę w poleceniu, to Git automatycznie zasugeruje, jakie polecenia prawdopodobnie próbowano wywołać. Git pozwala automatycznie wykonać sugerowane polecenie. W tym celu można skonfigurować opcję help.autocorrect. Autokorekta może działać w kilku trybach:

• immediate — Git automatycznie poprawi i wywoła polecenie w poprawionej wersji.
• n — n oznacza liczbę dziesiątych części sekundy, po której poprawione polecenie zostanie automatycznie zaaplikowane. Przykładowo ustawiając wartość 50, poprawione polecenie zostanie wywołane po 5 sekundach. Daje to użytkownikowi czas na przerwanie działania, np. przez Ctrl+C, zanim Git automatycznie wywoła poprawione polecenie.
• prompt — Git automatycznie poprawi i zapyta, czy wywołać poprawione polecenie. Osobiście preferuję ten wariant. Git może poprawić polecenie na jakieś, którego nie chcielibyśmy wywołać.

Lepszy diff

By usprawnić rezultaty wyświetlane przy git diff, warto zainteresować się dwoma opcjami. Pierwszą z nich jest pager. Pager to narzędzie, którego Git używa do wyświetlania danych wyjściowych w polecaniach takich jak git log, git show czy właśnie git diff. Dzięki wykorzystaniu pagera można przewijać zwrócone dane wyjściowe czy szukać określonych fraz. Domyślnie wykorzystywany jest less. Pager można skonfigurować, ustawiając wartość dla klucza core.pager. Dość popularną alternatywą dla less jest delta. Aby skorzystać z delty, musisz ją wcześniej doinstalować.

Sporą zaletą delty jest kolorowanie składni dla wybranych formatów treści czy bardziej czytelne wskazanie zmodyfikowanych linii (git config delta.line-numbers true).

Druga z interesujących opcji konfiguracyjnych pozwala na wybór algorytmu diffującego. Informację o wybranym algorytmie przechowuje klucz diff.algorithm. Domyślnym algorytmem jest algorytm Myersa (myers). Alternatywne algorytmy to:

• minimal to dokładniejsza wersja algorytmu Myersa — dąży do znalezienia najmniejszej możliwej liczby różnic, choć może działać wolniej.
• patience szuka najdłuższego wspólnego ciągu unikalnych i bardzo podobnych linii, które występują w obu wersjach pliku. Pomija mało znaczące linie, takie jak nawiasy czy puste wiersze, a zamiast tego skupia się na bardziej charakterystycznych elementach, np. definicjach funkcji. Dzięki temu zmiany są przedstawione w sposób bardziej czytelny i logiczny.
• histogram działa podobnie do patience, ale lepiej radzi sobie z powtarzającymi się liniami i zwykle jest wydajniejszy. Dobrze sprawdza się w większych plikach i przy złożonych zmianach. Jest to dość częsty wybór, także przez developerów rozwijających Gita.

W przyszłości na blogu planuję przygotować obszerny artykuł, gdzie szczegółowo zostaną omówione poszczególne algorytmy.

Podpisywanie commitów kluczem SSH

Git pozwala na podpisywanie commitów. Podpisywanie commitów to sposób cyfrowej weryfikacji ich autentyczności. Dzięki temu inni kontrybutorzy mogą zweryfikować, że dany commit został wykonany przez określoną osobę i nie został zmodyfikowany po podpisaniu. Jednym ze sposobów na podpisywanie commitów jest GPG (GNU Privacy Guard).

W większości tutoriali dotyczących Gita krok po kroku pokazuje się jak wygenerować klucz do podpisywania commitów. Jeśli jednak wykorzystujemy SSH, to nie ma potrzeby tworzenia osobnego klucza. Możemy skorzystać z klucza, który jest już znany przez wykorzystywany przez nas hosting Gita. Podpisywanie commitów za pomocą kluczy SSH działa w serwisach GitHub i GitLab. Jeśli korzystasz z innego rozwiązania, to upewnij się wpierw że wspiera ono taką możliwość.

W konfiguracji Gita należy ustawić opcję konfiguracyjną gpg.format na ssh oraz wskazać w opcji user.signingKey na lokalizację klucza publicznego.

W przypadku wykorzystania SSH Git może rzucić błędem error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification. Konieczne będzie wtedy utworzenie pliku allowed_signers i wskazania klucza, który może być wykorzystywany do podpisywania. Plik możemy stworzyć w lokalizacji z kluczami np. ~/.ssh/. Następnie w pliku należy dodać wpis w postaci: [identyfikator] [klucz publiczny]. Identyfikator powinien być zgodny z tym skonfigurowanym w user.email, a klucz powinien zawierać zarówno wartość klucza, jak i nagłówek. Ostatnim krokiem jest wskazanie lokalizacji pliku Gitowi poleceniem git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers.

Aby sprawdzić poprawność podpisu commita, użyj polecenia git log --show-signature 1. Oczekiwany rezultat to Good "git" signature for [identyfikator] with ED25519 key [fingerprint klucza].

Podsumowanie

Jeśli jesteś ciekaw, co jeszcze w Gicie warto skonfigurować, to koniecznie sprawdź mój projekt — Kolejna Książka o Gicie. Konfiguracja Gita to jeden z wielu aspektów, którą szczegółowo omawiam w tej książce. Zachęcam Cię do sprawdzenia, czego jeszcze możesz dowiedzieć się z tej książki. Zostaw swój adres e-mail, a dam Ci znać, gdy książka ujrzy światło dzienne.

Znasz jakąś ciekawę opcję konfiguracyjną, którą tu pominąłem? Daj znać w komentarzu!

Artykuł jest autopromocją Kolejnej Książki o Gicie.

Źródła i materiały dodatkowe

• Dokumentacja Gita – git config – Conditional includes
• Stefan Judis – git has an auto-correct flag
• Scott Chacon – Why is Git Autocorrect too fast for Formula One drivers?
• GitHub Docs – About commit signature verification
• GitLab Docs – Sign commits with SSH keys
• Scott Chacon – How Core Git Developers Configure Git
• Julia Evans – Popular git config options
• Lup Peng – When to Use Each of the Git Diff Algorithms
• GitHub – delta

Zaobserwuj mnie na LinkedIn!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zaobserwuj mój profil na LinkedIn, by być na bieżąco!
Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

Chcesz docenić moją pracę? Postaw mi kawę!