Transcription

Dzień dobry, witam bardzo serdecznie. W dzisiejszym materiale chciałbym opowiedzieć o siedmiu okropnych błędach przy używaniu gita. Mówiąc git, oczywiście mam na myśli system kontroli wersji. Dzisiejszy filmik będzie nieco luźniejszy, nie będzie żadnego tutoriala, więc materiał jest skierowany do osób, które już korzystają z gita. Oczywiście jeżeli chcesz się nauczyć gita, to mam do Ciebie parę linków w opisie do tego nagrania, ale dzisiaj będzie bardziej o tych okropnych i często popełnianych błędach, ale nie tylko będę mówił o błędach, ale też postaram się Wam przekazać parę rad i informacji jak tych błędów uniknąć oraz dlaczego warto ich uniknąć. Nie przedłużam więc i zapraszam do obejrzenia materiału. Pierwszy błąd to niekorzystanie z branży. Mam nadzieję, że nikt z Was nie pracuje w ten sposób, ale w skrócie chodzi o to, że jeżeli pracujesz na osobnym branczu, to tak naprawdę powoduje to, że możesz sam tam pracować i nikt za bardzo nie może Ci zakłócić pracy. I tutaj warto też mieć prefiks na dany typ brancza, czyli np. jeżeli pracujemy nad jakimś featurem, to nazwać naszego brancza feature ukośnik i np. registration albo feature ukośnik locals. I wtedy tylko patrząc na samą nazwę brancza, wiadomo co się w nim dzieje. Kolejna rzecz to rzadkie komity. I rzadkie mam na myśli po prostu, że ktoś nie robi tego często. A dlaczego warto robić często komity? No przede wszystkim, jeżeli komitujemy częściej, to jest mniejsze ryzyko wystąpienia konfliktów. A kto rozwiązywał w swoim życiu parę cięższych konfliktów, nie w życiu tylko w gicie, ten wie, że konflikty są rzeczą, której za bardzo nie lubimy, której warto jest unikać. No i właśnie takie częste komity, jak coś zrobię, zakomituję, pobieram najnowszą aktualizację brancza master i jestem w stanie np. zrebase'ować się z najnowszymi zmianami i wtedy mam pewność, że zawsze pracuję na najnowszym branczu. Jeżeli nie wiesz co to znaczy rebase'ować, o tym nie będzie, ten filmik zapraszam do opisu nagrania i można tam doczytać. Kolejną zaletą częstych komitów jest dla mnie bardzo proste raportowanie, czyli np. jeżeli ktoś się mnie zapyta Artur co robiłeś w środę, to po prostu odpalam swojego gitloga i widzę co robiłem w środę, to dosłownie komituję, jak tylko zrobię jakiś mały wycinek pracy, jakiś drobny komponent czy jakieś coś co jest ze sobą logicznie powiązane, od razu robię komit i wtedy jak ktoś mnie pyta co robiłem w środę, to od razu patrząc w historię gita jestem w stanie to powiedzieć. Kolejny częsty błąd wśród początkujących to zbyt ogólnie napisane komity w sensie wiadomości, czyli jeżeli dodajemy komita to oczywiście możemy dodać krótką notkę do tego komita. Problem jest taki, że często ludzie tam piszą update, feature, fix, hotfix i tak naprawdę później przeglądając historię gita ciężko jest powiedzieć co ktoś zrobił, bo trzeba się zagłębić i zobaczyć dokładne zmiany w plikach, bo po prostu z historii to nie wynika. Patrząc dalej, jeżeli macie na przykład w zespole testera i tester na przykład zastanawia się co wasz tak naprawdę branż zmienia i chce go przetestować, no to patrząc w wiadomości w gicie mniej więcej widzi i wie czego się spodziewać i wie na przykład w jakie zakamarki waszej aplikacji zajrzeć. No i tutaj też ode mnie taka rada, żeby używać angielskiego. Sami widzicie w tej prezentacji, że są słowa, które ciężko jest przetłumaczyć, na przykład komit, feature. Ja wiem, że są w internecie puryści języka polskiego, którzy ganią za to czemu używasz słowa komit, mogłeś użyć tutaj polskiego słowa. No nie, jesteśmy w informatyce i jednak niektóre słowa jakie przetłumaczysz to brzmią komicznie, więc uważam, że warto używać angielskiego, zwłaszcza, że tak naprawdę nie wiesz czy ktoś na przykład nie dołączy do ciebie z jakiegoś zagranicznego kraju i wtedy po prostu jest łatwiej. No i tutaj też radzę stosować taki szablon, czyli w momencie gdy zastanawiamy się nad tym jaką chcemy dodać wiadomość do tego naszego komita, no to przede wszystkim ważne, żeby ta wiadomość nie była dłuższa niż 50 znaków. Później warto jest stosować na przykład taką formułkę if applied this commit will i tu powinno wpasować się to co zrobiłeś w swoim komicie, czyli na przykład żeby nie używać tutaj czasu przeszłego albo czasu teraźniejszego, po prostu piszemy prostym angielskim style submit button fix typo, to jest w zupełności wystarczające. Nie musimy dodawać żadnej kropki, zaczynamy z wielkiej litery, jeżeli chcecie w swoim komicie napisać dokładnie co ten komit zrobił i dlaczego, to oczywiście jest to wskazane, jest to możliwe, może nie, że wskazane, ale można to robić, to wtedy po prostu piszecie ten pierwszy message na 50 znaków i robicie nową linię i tam sobie możecie napisać, no zrobiłem to tak, tak i siak, bo wystąpił tam jakiś problem, ale ważne, żeby ta pierwsza linijka zawsze, ten nagłówek miał zawsze mniej więcej jak 50 znaków. Częsty błąd, myślę, że nawet bardzo częsty, czyli komitowanie bez przetestowania czegoś i do czego to tak naprawdę prowadzi? No prowadzi to do takich sytuacji, że później w historii robi się bałagan, bo coś wrzuciłem, ale nie przetestowałem, w międzyczasie pojawiły się jakieś inne komity, więc muszę wrócić do tego. Później tak naprawdę code review może też być niezbyt produktywny, bo ktoś już nam oceni nasz kod, przejrzy go, a później przez to, że nie przetestowaliśmy jakiegoś małego szczególiku, to na przykład coś trzeba zmienić i ktoś musi później zrobić ten code review jeszcze raz. Więc taka ważna rada też, taka oczywista oczywistość, żeby testować Wasz kod przed komitem. Kolejna rada to automatyzujcie co się da, czyli jeżeli na przykład w Waszym projekcie używacie jakichś linterów, macie jakieś automatyczne testy, no to może warto wtedy skorzystać sobie z jakichś takich bibliotek, które na przykład przy dodawaniu komitu odpalają jakiś określony kod. Ja na przykład mam tutaj jeden projekt taki, z którego widzicie screenshot, w którym odpalany jest eslint i w momencie, gdy ktoś chce dodać komit taki, który po prostu rozwala lintera, no to wtedy użytkownik jest o tym poinformowany i już niektóre rzeczy tak naprawdę nie wychodzą na code review czy na jakichś dalszych procesach, bo zautomatyzowaliśmy to i jakby nasza linia poleceń strzeże takich rzeczy. Oczywiście wiem, że są sytuacje, kiedy trzeba olać lintera, bo coś nie działa i trzeba wrzucić komit natychmiast, to oczywiście wtedy jest to dozwolone i używamy na przykład tutaj tak jak w tym sofcie Husky no verify i wtedy nie jest odpalany po prostu ten hook, który odpala eslinta. Oczywiście w Waszym projekcie mogą być inne rzeczy, nie mówię, że zawsze jest to akurat najlepsze rozwiązanie, ale jeżeli macie jakieś takie wewnętrzne ustalenia w Waszym zespole, że na przykład przed zgłoszeniem się do code review trzeba odpalić linter albo jakieś inne narzędzia, no to warto to sobie po prostu zautomatyzować, żeby nie musieć o tym pamiętać. Kolejny błąd myślę początkujących osób to jest dodawanie generowanych plików, czyli jeżeli macie w aplikacji jakieś swoje logi, jeżeli macie jakieś pliki powiązane z kontem Waszego użytkownika testowego, to nie ma zupełności sensu, żeby wrzucać te pliki do gita, bo po pierwsze jeżeli ktoś kiedyś je ściągnie na swoim komputerze to najprawdopodobniej mogą i tak te wszystkie pliki nie zadziałać, bo jest jakiś określony stan w bazie danych do tego wymagany. Do tego dochodzą jakieś systemowe pliki, nie wiem, Windows generuje jakieś ukryte pliki pomocnicze jak wyświetlarz zdjęcia, żeby tam się miniaturki szybciej ładowały. Wszelkie takie rzeczy nie są potrzebne w repozytorium, więc po prostu ich nie dodajmy. Później są, jeżeli macie w swoich projektach jakieś generatory, jakichś plików, że trzeba uruchomić jakąś komendę i Wasz soft coś tam w tle mieli i wypluwa ten plik, no to po prostu też nie ma sensu wrzucać tego pliku do repozytorium, bo wtedy warto zastanowić się po prostu, żeby poinformować kogoś w jakiejś dokumentacji, w pliku readme, że trzeba sobie coś wygenerować, ale nie dodawać tego po prostu do repozytorium. Oczywiście też jakichś takich wielkich plików, jak macie jakieś pliki, nie wiem, filmy, jakieś potężne kolekcje zdjęć, no wtedy też warto się zastanowić, czy warto to wrzucać do gita, czy jakoś to po prostu w inny sposób rozwiązać. Kolejny błąd to wrzucanie do repozytorium sekretów, czyli jeżeli macie jakieś połączenie np. do AWS, jeżeli macie jakieś hasło do bazy danych, jeżeli macie jakieś klucze prywatne, które pozwalają Wam korzystać z jakiejś usługi, to nigdy nie wrzucajcie tego do repozytorium. Po pierwsze, były już takie przypadki w projektach open source, że ktoś coś wrzucił na GitHuba i są po prostu roboty, które wręcz indeksują te wszystkie kody i szukają właśnie takich kluczy, by je wykorzystać w niecnych celach, więc broń Boże, nigdy nie wrzucajcie sekretów do repozytorium. Najlepiej jest sekrety trzymać w jakichś plikach konfiguracyjnych, które nie lecą do repo, ale tu też ważna rzecz, żeby w momencie, kiedy macie jakieś sekrety, kiedy macie jakieś pliki konfiguracyjne, to żeby dawać takie przykładowe pliki, czyli jeżeli macie plik np. sekret.config.json i nie chcecie, żeby ten plik się znalazł w Waszym repozytorium, to wtedy dodajecie sobie np. sekret.config.example.json i wrzucacie do repozytorium taki plik z przykładowymi sekretami, tak żeby później osoba, która ściągnie sobie Wasz projekt, żeby wiedziała w jakiej strukturze należy umieścić te sekrety, bo czasami po prostu jak się ściągnie, to może Wasza aplikacja rzucić jakimś błędem, jakąś piętsetką brzydką, z której nie wiadomo w ogóle o co chodzi. A się okazuje, że po prostu jest to błąd wynikający z tego, że ktoś nie wrzucił sekretu, więc dlatego warto za każdym razem wspomnieć o tym w dokumentacji albo przynajmniej przygotować takie przykładowe pliki. Kolejny częsty błąd to brak reguł gry, czyli tak naprawdę macie zespół pięciu osób, piszecie sobie jakąś appkę i każdy sobie rzepkę skrobie. Jeden zrobi na przykład brancza nazwie Artur, drugi sobie nazwie brancza tam random, trzeci będzie pisał komity tak, ktoś tam będzie komity pisał inaczej. No i wtedy, kiedy nie ma takich reguł gry, no to jest ciężko się później połapać w historii takiego projektu. Wygląda to bardzo nieprofesjonalnie, więc ja zalecam zawsze ustalić wewnętrznie ze swoim zespołem jakie chcemy pisać wiadomości, w jakim formacie. Czy korzystamy z linterów, czy odpalamy testy przed code review, jak nazywamy nasze brancze, czy piszemy jakieś opisy do komitów, jak oznaczamy hotfixy. No to są rzeczy, które po prostu trzeba ustalić ze swoim teamem i nigdy myślę, że nie można zostawiać tego dziełu przypadku, czy żeby właśnie każdy zrobił co chce, warto jest to po prostu ustalić. No i podsumowanie, używajcie branczy, często komitujcie, dbajcie o treść waszych komitów, testujcie przed komitami, automatyzujcie co się da tak, żeby minimalizować ryzyko zapomnienia o czymś, bądź spędzania często czasu na tych samych czynnościach. Ignorujmy niepotrzebne rzeczy, tu oczywiście chodzi mi o plik gitignor, czyli właśnie ignorowanie jakichś śmieci, logów, jakichś generowanych przez testy plików, one nie są potrzebne w repozytorium. Nigdy nie komitujcie do repozytorium sekretów, w ogóle zawsze jeżeli piszecie gdzieś w kodzie jakiś sekret, to po prostu od razu powinna wam się zapalić lampka w głowie, żeby nie zostawić tego w kodzie, tylko po prostu posłużyć się zmienną środowiskową albo jakimś plikiem konfiguracyjnym i stamtąd zaciągać ten sekret. No i na koniec ustalcie reguły gry ze swoim zespołem, czyli po prostu jeżeli jesteś w projekcie gdzie jest więcej niż jedna osoba, to umówcie się w jaki sposób chcecie ze sobą pracować, a będzie po prostu łatwiej. No i to wszystko w zasadzie co przygotowałem dla was w tym dzisiejszym nieco luźniejszym filmiku. Dajcie znać w sekcji komentarzy czy filmik się podobał, czy macie jakieś inne uwagi do pracy z gitem lub jakieś częste błędy bądź problemy, a spróbuję się do tego odnieść. Dzięki za uwagę, trzymajcie się, cześć. Napisy stworzone przez społeczność Amara.org