Jest GIT? Musi być! Na początek kilka dosłownie słów na temat tego cudeńka. GIT jest rozproszonym systemem kontroli wersji (DVCS – Distributed Version Control System). Git przechowuje i traktuje informacje kompletnie inaczej niż te pozostałe systemy, mimo że interfejs użytkownika jest dość zbliżony. Rozumienie tych różnic powinno pomóc Ci w unikaniu błędów przy korzystaniu z Git. Podstawową różnicą pomiędzy Git a każdym innym systemem VCS (włączając w to Subversion) jest podejście Git do przechowywanych danych. Większość pozostałych systemów przechowuje informacje jako listę zmian na plikach. Systemy te (CVS, Subversion, Perforce, Bazaar i inne) traktują przechowywane informacje jako zbiór plików i zmian dokonanych na każdym z nich w okresie czasu. Git podchodzi do przechowywania danych w odmienny sposób. Traktuje on dane podobnie jak zestaw migawek (ang. snapshots) małego systemu plików. Za każdym razem jak tworzysz commit lub zapisujesz stan projektu, Git tworzy obraz przedstawiający to jak wyglądają wszystkie pliki w danym momencie i przechowuje referencję do tej migawki. W celu uzyskania dobrej wydajności, jeśli dany plik nie został zmieniony, Git nie zapisuje ponownie tego pliku, a tylko referencję do jego poprzedniej, identycznej wersji, która jest już zapisana. 

Więcej informacji dotyczących samego GIT’a znajdziesz w książce „Pro GIT” Scotta Chacona, dostępnej online pod adresem http://git-scm.com/book/pl.

Jeśli nie zanudziłem Cię jeszcze podstawowymi informacjami zapraszam do sedna tematu. Teraz „zjemy naszą wisienkę”. Używasz GIT, ale nie wiesz jak wykorzystać cherry-pick, bo korzystasz z GIT GUI lub TortoiseGIT? W tej kwestii polecam zapytać wujka Google, bowiem osobiście korzystam niemal zawsze z konsoli GIT Bash i nie mam pojęcie jak to wygląda „w okienkach”. Niemniej zachęcam nadal do korzystania z konsoli 🙂

Wyobraźmy sobie pewną sytuację. W repozytorium posiadamy gałąź produkcyjną i rozwojową. Produkcyjna zawiera migawkę ze stabilnej wersji systemu, który jest wdrożony do publicznego dostępu (lub lokalnego, zależy od tego czy aplikacja jest wewnętrzna, czy zewnętrzna). Gałąź rozwojowa to nic innego jak zmiany mające na celu ulepszenie wersji produkcyjnej. Taka sytuacja jest stosunkowo często spotykana.

W pewnym momencie otrzymujemy informację od szefa (oczywiście po akceptacji testera 🙂 ), że funkcjonalność Y ma być natychmiastowo wdrożona na produkcję. Początkujący „gitowiec” wpadłby w zakłopotanie. Ale nie ma co się zamartwiać. Tutaj z pomocą wędruje do nas komenda cherry-pick, której zadanie po krótce polega na dołączaniu zmian z wybranych commitów z jednej gałęzi do drugiej. Jeżeli nasza funkcjonalność Y powiązana jest z jedną migawką to wystarczy jedna komenda

git cherry-pick SHA1

która dociąga zmiany z określonego commita (innej gałęzi!) do obecnej gałęzi. W przypadku, gdy nie występują konflikty tworzona jest nowa migawka na bieżącej gałęzi i mamy zaktualizowaną wersję produkcyjną aplikacji. Możemy planować wdrożenie!

[1] Dokumentacja GIT cherr-pick:  https://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html