Praktyczny kurs GIT dla zielonych cz. 3 – Konflikty, .gitignore i Pull Requesty

Pull Requesty

Pull Request (często stosowany skrót PR) to alternatywny sposób mergowania branchy. Można go robić z komend, ja jednak preferuje wejść na stronę internetową hostingu naszego repozytorium i zrobić to za pomocą interfejsu. Co to nam konkretnie daje? Pull Requesty umożliwiają przeglądanie zmian przed dokonaniem merg’a, sprawdzą i poinformują nas zawczasu, czy nie ma konfliktów. Pull Requesty również można komentować, dzięki czemu przed ostatecznym mergem, będzie można coś jeszcze poprawić po czyjejś sugestii. Process Pull Requesta polega na porównaniu naszego branch’a z branchem docelowym i wylistowaniu commitów, które wprowadzają zmiany. W dobrze rozwiniętych projektach ze zintegrowanymi narzędziami do testowania, istnieje możliwość ustawienia automatu, który każdy Pull Request będzie stawiał lokalnie i testował wcześniej napisanymi testami. Wreszcie, Pull Requesty może robić każdy, kto ma dostęp do repozytorium (chyba że się tę opcję zablokuje). W ten sposób rozwijają się projekty Open-Source. Istnieje jeden główny zarządca repozytorium (ew. grupa takich osób), który przegląda Pull Requesty od społeczności i po sprawdzeniu może ewentualnie te zmiany zaakceptować i domergować.

Pull Request – zrób to sam!

Spróbujmy samodzielnie zrobić przykładowy pull request. W tym celu zrobimy branch o nazwie lets-merge-a-pull-request, dodamy jeden commit ze zmianami, spushujemy zmiany na serwer, a na koniec wykonamy Pull Request poprzez stronę hostingu (w tym przypadku github’a). Lokalne czynności zrealizuję za pomocą następujących komend:

Aby wykonać Pull Request wchodzimy na hosting naszego repozytorium i klikamy jeden dowolny z dwóch zaznaczonych przycisków.

W wyniku przejdziemy na stronę zawierającą podsumowanie przyszłego Pull Requesta:

Kiedy wybierzemy branch, który chcemy zmergować, oraz branch do którego mergujemy wystarczy klinknąć Create pull request. Pull Request powinien zostać utworzony i oczekiwać zaakceptowania przez osoby zarządzające repozytorium.

Po akceptacji Pull Requesta, automatycznie nastąpi merge zawierający zmiany wypisane w powyższym podsumowaniu. Bardzo ważną przewagą Pull Requestów nad mergami jest to, że w każdej chwili po zmergowaniu możemy jednym przyciskiem utworzyć kolejnego pull requesta, usuwającego zmiany wprowadzone przez aktualnego PR’a.

Po zmergowaniu pull requesta należy pamiętać, aby spullować zmiany z repozytorium zdalnego do lokalnego, gdyż cały proces PRa wykonywany jest na repozytorium zdalnym.

Kiedy używać Pull Requestów?

Pull Requesty to genialne narzędzie, ale jednak uciążliwe. Jeśli często robimy commity i merge, nie chcemy przecież za każdym razem przechodzić przez proces tworzenia Pull Requesta. Przyjmuje się zatem (oczywiście zależnie od zdefiniowanych przez osoby zarządzające repozytorium zasad), że zazwyczaj PRy wykonujemy tylko do branchy ważnych, które zawsze muszą działać (takich jak np master, w niektórych projektach również dev). Wtedy w przypadku problemów z PRem, zawsze można go szybko revertować. W pozostałych branchach które na bieżąco mergujemy, testujemy, poprawiamy i tak w kółko do osiągnięcia zadowalającego efektu, nie ma potrzeby używać za każdym razem PRów i można zadowolić się zwykłymi mergami.

Podsumowanie

Umiejętność rozwiązywania konfliktów, wykonywania Pull Requestów są bardzo cenione, w każdym szanującym się projekcie. Istnieje też duża szansa, że na rozmowie kwalifikacyjnej w firmie, która używa Git’a można zostać zapytanym o któreż z powyższych lub przyszłych zagadnień. Nie są to już absolutne podstawy, jakie wymaga się od studenta robiącego projekt prostej aplikacji, a wiedza ułatwiająca bezproblemowe zarządzanie kodem projektu, w skład którego wchodzi wiele osób. Jeśli coś opisałem niedokładnie lub błędnie to, jak zawsze, proszę o kontakt np. w komentarzach 🙂