Git logo
Narzędzia używane w Droptica - część 3 - repozytorium plików

Czas na kolejną porcję informacji o tym, jak pracujemy w firmie Droptica. Dzisiaj będzie o wersjonowaniu plików oraz o testowaniu aplikacji.

Subversion

Początkowe projekty realizowane na Drupalu (jeszcze jako OPENBIT) używały systemu Subversion (znany również jako SVN, strona projektu https://subversion.apache.org/) do wersjonowania plików. Jednym z takich projektów był system intranetowy dla firmy Telefonia Dialog S.A. (case study: http://www.droptica.pl/case-study/dialogownia).

SVN, jak inne systemy wersjonowania, pozwala na trzymanie historii zmian plików. Główną różnicą między SVN a GIT (o nim za chwilę) jest to, że w SVN repozytorium jest trzymane na jednym zdalnym serwerze, do którego wszyscy wprowadzają zmiany. Wymusza to commitowanie tylko do zdalnego serwera, nie można commitować tylko lokalnie nieskończonych zmian. Z SVN pojawiały się czasem trudne do rozwiązania konflikty (2 osoby pracowały na tych samych plikach). Niewygodne było także zarządzanie branchami i ich łączenie.

GIT

W 2012 roku rozpoczęliśmy pierwsze próby z użyciem GITa na projektach. Pierwszą "dziwną" rzeczą było to, że aby wysłać zmiany na serwer, nie wystarczyła komenda "commit", potrzebna była dodatkowa komenda "push". Tego dodatkowego kroku nie było w SVN. Wynika to z tego, że GIT jest systemem rozproszonym, czyli repozytorium nie jest trzymane na jednym serwerze, ale w wielu miejscach (np. na komputerach programistów, serwerach testowych, itp).

W GIT commitujemy do repozytorium, które mamy lokalnie na komputerze, a następnie synchronizujemy nasze zmiany (commity) z innym repozytorium. Z reguły ustala się jedno zdalne repozytorium jako to główne miejsce na wypychanie zmian. Nie ma jednak żadnych przeszkód, aby jeden programista wypchał swoje zmiany do repozytorium na komputerze drugiego programisty (potrzebny dostęp np. przez SSH), drugi programista kończy zadanie i dopiero wypycha zmiany na zdalny główny serwer.

GIT bardzo dobrze radzi sobie z łączeniem zmian wprowadzanych w tym samym pliku. Wygodne też jest łączenie gałęzi (branchy) w repozytorium. Przez bardzo wielu użytkowników GIT jest uważany za bardzo dobry system wersjonowania i my się z tą opinią w pełni zgadzamy.

GIT GUI

GIT jest aplikacją konsolową, czyli aby go używać, należy wprowadzać komendy w terminalu. Dla początkujących użytkowników może być to trudne, dlatego na początek polecamy użycie graficznej nakładki na GIT. Kilka przykładów takich programów poniżej:

Smartgit

Jest jeszcze wiele innych programów tego typu, wystarczy wpisać w Google: GIT GUI. Nie wszystkie jednak działają na Linux, Windows i MacOS jednocześnie.

Jeśli używacie graficznych programów do GIT, a nie ma ich na liście, to napiszcie ich nazwy w komentarzu. Może się to przydać innym osobom korzystającym z GITa.

Git-flow

W GIT możemy tworzyć branche (gałęzie). Dzięki branchom możliwa jest praca nad zadaniem obok głównego sprawdzonego już kodu. W skrócie praca wygląda tak:

  • rozpoczynamy prace nad nowym zadaniem programistycznym
  • tworzymy nowy branch
  • wykonujemy zadanie w branchu
  • testujemy zadanie w branchu
  • po przejściu testów i code review branch jest dołączany (merge) do głównego brancha

Takie operowanie na branchach wymaga kilku powtarzających się komend. Aby to usprawnić,  powstał Git-flow, czyli rozszerzenie do GITa dodające nowe komendy. Dokładny opis modelu tworzenia branchy używanego przez Git-flow znajdziecie na stronie http://nvie.com/posts/a-successful-git-branching-model/

W Droptica używamy git-flow i bardzo chwalimy to podejście. Pozwala nam to na eliminację błędów w realizowanych zadaniach przed dołączeniem kodu do głównej gałęzi. W ten sposób mamy zapewnione, że główny branch ma tylko przetestowane kody.

git-flow

Github

Większość kodów projektów trzymamy w prywatnych repozytoriach w serwisie GitHub.com. Używamy Githuba, ponieważ zapewnia stabilne serwery do przechowywania plików oraz oferuje opcję “Pull request”.

Pull request jest to żądanie połączenia jednego brancha do drugiego, np. połączenie brancha jednego programisty do głównego brancha aplikacji. W czasie tworzenia pull request możemy zobaczyć podsumowanie zmian pomiędzy dwoma branchami. Jeśli programista w swoim branchu zrobił kilka commitów, to wszystkie commity zostaną “połączone” w jedną zmianę. Zobaczymy wtedy przejrzyste porównanie zmian w kodzie, jakie zostaną wykonane po akceptacji pull request (zostanie wykonana operacja merge).
 

github pull request

Taki pogląd pozwala na bardzo łatwy przegląd kodu. W ten sposób główny programista na projekcie może szybko zweryfikować, czy zmiany innego programisty są poprawne i możliwe do zmergowania. Przegląd kodu w pull request przez drugą osobę gwarantuje nam to, że kod w aplikacji zna zawsze minimum 2 osoby.

To już trzeci wpis z serii, jednak nie ostatni. Mamy jeszcze kilka narzędzi, które będziemy opisywać na blogu w kolejnych dniach lub tygodniach.

 

Porozmawiajmy o Twoich projektach

Napisz do nas!