Najczęściej w pracy do tworzenia commitów używam IDE IntelliJ. Jest to naprawdę świetne narzędzie: pozwala w jednym oknie dialogowym przejrzeć jeszcze raz diff zmian, pominąć niektóre pliki albo nawet części plików, sprawdza pisownię, podpowiada poprzednie opisy zmian. Czasem jednak zdarza mi się tworzyć commity bezpośrednio z linii komend — zwłaszcza gdy projekt nie jest pisany w Javie/Kotlinie, nie chce mi się czekać na kobyłę, jaką jest IntelliJ — zmieniam coś prostym edytorem tekstowym lub graficznym i odpalam wprost git commit. Domyślnie w Ubuntu przy tworzeniu commitu otwiera się bardzo prosty edytor nano. Ja sam używałem nano z Gitem od wielu lat, od pół roku jednak opisy zmian i podobne teksty zmieniam w Vimie. Napiszę teraz krótko, czemu moim zdaniem to świetny wybór i co ustawić, żeby dać szansę takiej kombinacji.
Spis treści
Context switching to zło a szybkość ma znaczenie
Vim nie jest programem prostym do opanowania i rozumiem wątpliwości co do mojego wyboru. Co mną kierowało? W tych wypadkach, gdy akurat pracuję w linii komend zamiast w IDE, staram się minimalizować korzystanie z edytorów graficznych, bo latające okienka są rozpraszające. Jeszcze przy zapisywaniu od czasu do czasu pojedynczego commita dałbym być może radę znieść Kate’a czy innego GEdita, ale gdy robię bardziej skomplikowanego rebase’a, edytor graficzny powodowałby koszmarny context switching. W takim wypadku najpierw edytuję plan rebase’a, potem grupuję 5-10 roboczych commitów w jeden, dwa a czasem trzy logiczne commity, wreszcie squashując każdą grupę muszę w edytorze przejrzeć zlepione przez Gita opisy zmian i zrobić z nich coś czytelnego dla człowieka. Powtarzałby się wtedy kilka razy następujący scenariusz: robię coś w linii komend, nagle na terminal zaczynają być wypluwane komunikaty o starcie programu okienkowego, tracę możliwość pisania w terminalu, muszę chwilę poczekać na narysowanie okienka edytora i moment, aż przejmie focus. Jeśli będę niecierpliwy i zacznę pisać za szybko, część tekstu pójdzie do terminala i zepsuje poprawność linii komend, a niekompletna reszta trafi do edytora, będę musiał przerwać pisanie i wracać do początku tekstu, żeby uzupełnić początek. Potem zapisuję zmiany, czekam aż edytor się zamknie, wypluwając kolejne śmieci na terminal, i wracam do pracy w konsoli, zastanawiając się, co właściwie miałem przed chwilą zrobić.
Wracanie się, żeby poprawiać tekst, oraz context switching to zabójcy programistycznego flow. Pisałem o tym przy okazji importów i świetnej książki Pragmatic Thinking and Learning. Edytor tekstowy uruchamia się szybko, nie gubi focusu, umożliwiając nieprzerwane pisanie, nie używa też zupełnie odmiennego wyglądu niż terminal, powinien więc znacząco zmniejszać rozproszenia. Dodatkowo edytory tekstowe nie wypluwają śmieci przy otwieraniu i zamykaniu, nie zamazują więc tego, co akurat robimy w konsoli.
Czemu nano to za mało
Tak jak wspominałem, bardzo długo korzystałem z nano. Jest to prosty edytor: jego ekran bez potrzeby wydawania jakichkolwiek komend podpowiada, jak wycinać i wklejać tekst, oraz, co ważne dla osób straumatyzowanych pierwszym kontaktem z Vimem, jak zakończyć działanie nano ;-) Do tego opłaca się go znać, bo na różnych systemach uniksopodobnych nano jest chyba najbardziej rozpowszechnionym edytorem. Jeśli wchodzimy przez ssh na jakąś maszynę albo siadamy przy cudzym komputerze, może tam nie być Basha, może tam nie być Vima, ale nano najprawdopodobniej będzie.
Jednak w miarę pracy z IntelliJ zacząłem zauważać, jak wielu rzeczy brakuje mi w nano jako edytorze dla Gita. Łatwo jest popełnić błąd pisowni. Nie widać, kiedy łamię zasady pisania opisów zmian, na przykład co do długości linii. Przy squashowaniu często kasuję wiele linijek, nie chciało mi się naciskać z prędkością karabinu maszynowego Ctrl+K, a przytrzymywanie tego skrótu było mało precyzyjne. Brakowało mi zaznaczania rzeczy do skasowania na przykład strzałkami. Plan rebase’a to mnóstwo tekstu i przy braku kolorowania wszystko zlewało mi się. Plus brakowało mi wygodnego sposobu na przestawianie grupy commitów z „pick” na „squash” — find/replace w nano wymaga naprawdę dużo pisania, trzeba też było uważać, żeby nie podmienić pierwszego wystąpienia.
Mogłem douczyć się nano i spróbować część z tych rzeczy dokonfigurować. Znałem jednak trochę Vima i postanowiłem go wypróbować w takim użyciu. Spotkało mnie pozytywne zaskoczenie — na dzień dobry działa naprawdę świetnie z Gitem, nie trzeba nic robić, żeby działało np. kolorowanie. Nano nie ma ambicji być bardzo rozbudowanym edytorem, a ja stwierdziłem, że w sumie przyda mi się narzędzie, którym od czasu do czasu mógłbym na serio edytować kod w linii komend. Postanowiłem więc, że zainwestuję trochę w naukę Vima, a dostanę sprawny edytor dla Gita, do kodu i plików konfiguracyjnych.
Jak zacząć
W Ubuntu od pewnego czasu nano zastąpiło Vima jako domyślny edytor systemowy. Zacząłem od zmiany tego za pomocą update-alternatives. Nie trzeba dodatkowo konfigurować Gita, który bierze właśnie edytor systemowy, o ile gitconfig nie mówi inaczej. Co do konfiguracji Vima to zdałem się na Ubuntu — domyślna działała wystarczająco dobrze i nie czułem potrzeby zmian.
Jeśli ktoś chce wypróbować Vima w Gicie bez mieszania w konfiguracji całego systemu, polecam zmienić tylko ~/.gitconfig. Ja wpisałem tam Vima po to, by móc uruchamiać edytor z trochę innymi opcjami pod kątem wykorzystania w Gicie. Ustawiam w ten sposób długość linii na typowe dla Gita 80 znaków — dla innych plików nie stosuję takiego ograniczenia.
[core]
editor = vim -c \":set colorcolumn=80\"
Poniżej widać, jak Vim pomaga w pisaniu poprawnych opisów zmian. Pierwsza linijka zmienia kolor, gdy przekroczymy limit 50 znaków. Na czerwono podświetlona jest druga linijka, która jest wypełniona, chociaż powinna być zostawiona pusta. Czerwona kreska w 80 kolumnie to zasługa ustawionej przeze mnie opcji colorcolumn.
Więcej możliwości
Zalety Vima widać też przy interactive rebase — podświetlanie składni naprawdę pomaga:
Vim może też sprawdzać pisownię:
Nie włączyłem tej opcji domyślnie, ponieważ nie sprawdza się przy rebasie: połowa ekranu świeci się na czerwono, głównie hashe commitów. Włączam sprawdzanie pisowni ręcznie, komendą :set spell.
Wygodnie kasuje się wiersze — można wcisnąć v, wtedy w trybie wizualnym działają strzałki i delete. Albo można skasować wybraną liczbę wierszy: 3dd to kasowanie trzech itp.
Jeśli chodzi o masowe zmienianie „pick” na „squash” to korzystam z dwóch możliwości oszczędzających uderzenia w klawiaturę. Po pierwsze, Vim ma historię poleceń. Mogę pokazać listę wszystkich ostatnich poleceń (dwukropek a potem Ctrl+f), albo wpisać początek :%s i wcisnąć strzałkę w górę i znajdzie mi :%s/pick/squash/gc. Drugą opcją jest tryb wizualny i zaznaczenie pionowego bloku tekstu a następnie wyedytowanie go.
Nauka Vima
Vim jest edytorem trudnym do opanowania nie tylko ze względu na skróty klawiaturowe i zachowania zupełnie odmienne od programów graficznych a nawet prostych edytorów tekstowych, ale też złożoność koncepcji, na których jest oparty. Wymaga na start sporej inwestycji w naukę, ale według mnie warto, by w sytuacji braku dostępu do trybu graficznego (np. awaria systemu) mieć wiedzę o edytorze tekstu, który potrafi więcej niż tylko kopiować i wklejać wiersze.
Mimo wszystko do pracy nad bardziej skomplikowanymi tekstami wolę tryb graficzny, więc okazji do korzystania z edytorów tekstowych wcale nie mam tak dużo. Uznałem, że muszę dobrze wykorzystać te okazje, które mam, więc zarzuciłem zupełnie nano i jeśli gdziekolwiek mam wyedytować coś w trybie tekstowym, używam wyłącznie Vima. Staram się też korzystać częściej z Vima zamiast edytora okienkowego, gdy jestem w konsoli i mam coś otworzyć do edycji. Mam dokument w chmurze z moimi notatkami, jak robić w Vimie rzeczy, które potrzebuję — zaglądam tam, gdy czegoś zapomnę. Nie jest trudno znaleźć w wyszukiwarce strony internetowe dostarczające odpowiedzi na typowe problemy. Na razie taki niepełny poziom znajomości Vima mi wystarcza. Czuję, że nawet nie będąc vimowym guru jestem w stanie korzystać z Gita bardziej efektywnie.
