gitWeb – branching cz.2

W dzisiejszym wpisie chciałbym omówić kolejne funkcjonalności modułu odpowiedzialnego za branching. W poprzednim wpisie opisałem następujące kwestie:

  • Lista branchy
  • Tworzenie nowego brancha

Dzisiaj skupię się na:

  • Checkout – przełączanie się pomiędzy branchami
  • Pobranie drzewa comitów dla aktualnego brancha
  • Opisanie na drzewie commitów, dostępnych branchy

Checkout

Git

Podstawowa funkcjonalność gita, bez której nie da się działać pracując w środowisku z wieloma branchami. Pozwala na przełączenie się pomiędzy dwoma branchami. W konsoli operacja dostępna pod komendą:

Najważniejsze kwestie jakie należy wziąć pod uwagę korzystając z tej komendy to:

  • Wszystkie zmiany, które posiadamy na aktualnym branchu przeniosą się na nowy branch. Oczywiście, jeżeli wystąpi konflikt to zostaniemy o tym poinformowani.
  • Przełączenie się na nowy branch powoduje, że HEAD repozytorium ustawi się na Tip danego brancha. Innymi słowy, zostanie pobrany stan repozytorium z najnowszego commita na nowym branchu.

Tip w branchu, jest to najnowszy commit zrobiony na danym branchu.

VueJs

Po stronie widoku za wiele się nie dzieje. Wywołane kolejne akcje, które na końcu wywołują API. Jedyną rzeczą, na którą chciałem zwrócić uwagę jest główny plik actions.js w sekcji store.

Generalnie chciałem zmodularyzować Vuex w obrębie głównych komponentów Vue. A więc, miałem moduł Vuex branchArea.js, który odpowiadał komponentowi branch.vue, itd.

Aby była możliwa komunikacja między tymi modułami, wydzieliłem nadrzędne miejsce, w którym akcje będą je spajać.

W tym konkretnym przypadku akcja checkout znajduje się w pliku nadrzędnym actions.js, a sama akcja prezentuje się następująco:

Wywołana sekwencja kolejnych akcji. W pierwszej kolejności wywoływany jest CHECKOUT_BRANCH na wskazanym przez użytkownika branchu. W momencie gdy operacja zakończy się sukcesem wywoływana jest akcja GET_COMMIT_TREE_FROM_HEAD, która pobiera listę commitów, zaczynając od HEAD „nowego” brancha. Na samym końcu wywoływane jest builder odpowiedzialny za kompozycję grafu.

Api

Aby przełączyć branch należy odwołać się do:

Sam kontroler wygląda tak samo jak w poprzednich wpisach, a więc przejdę od razu do właściwej implementacji przy pomocy libgit2sharp:

I pojawia się… Magiczne Commands. Z jakiegoś powodu autorzy biblioteki postanowili, że wydzielą część funkcjonalności do statycznych metod. Oczywiście, to jest OS projekt i rozumiem dlaczego wszystko co miało by trafić do commands, jeszcze tam nie trafiło. Ja mam z tym jeden problem, mianowicie dość ciężko do statycznych metod pisze się testy, trzeba je oklejać jakimiś wrapperami, żeby móc mockować takie wywołania.

Poza tym kawałek kodu dość standardowy, parę sprawdzeń warunków brzegowych, zwrócenie NullObject w momencie gdy branch nie istnieje i translacja do obiektu DTO.

Pobranie drzewa commitów dla aktualnego brancha

Tu sprawa wygląda bardzo prosto. Komenda:

pobiera zawszę listę commitów zaczynając od HEAD aktualnego brancha, na którym się znajdujemy.

Pobieranie listy commitów oraz budowanie z nich branchy opisałem we wpisie dotyczącym komendy git log –graph, serdecznie do niego zapraszam.

Opisanie na drzewie commitów branchy

Na powyższym gifie w prawej stronie widać skromnie wyglądające labele BRANCH. Reprezentują one „status” aktualnego brancha. A więc pokazują się tam wszystkie branche przypisane do commita „widocznego” z poziomu obecnego brancha.

Zadanie do zrealizowania może brzmieć następująco:

Pokaż wszystkie branche których najnowszy commit znajduje się na grafie aktualnego brancha.

Powyższa metoda robi dwie rzeczy. W pierwszej kolejności pobrana jest lista commitów dla aktualnego brancha. Następnie pobrany jest Tip każdego dostępnego brancha. Mając te dwie informacje możemy w prosty sposób zmapować te dwie kolekcje.

Podsumowanie

Komponent zbudowany… ale nie kompletny. Brakuje w nim jeszcze wielu, wielu rzeczy. Między innymi zmiana nazwy, usuwanie, „śledzenie” branchy zdalnych. Operacja Checkout wiąże się również z konfliktami i mergowaniem. Jak widać sporo pracy jeszcze przede mną.

W tych dwóch wpisach opisałem budowę jednego z wielu komponentów, które będą budować moją aplikację. Oprócz samego opisywania kodu, chciałem również wrzucić troszkę teorii dotyczącej samego gita. Chciałbym w dalszym ciągu pisać w takiej konwencji. Dzięki temu mam zamiar wprowadzić trochę urozmaicenia i ciekawej wiedzy we wpisy.

W tym momencie kończę kolejny spory moduł. Jeszcze przed świętami chciałbym opisać część dotyczącą tworzenia commitów i podglądu zmian w plikach.