W poprzednim etapie wprowadzenia do środowisk Git i GitHub podjęliśmy między innymi takie pojęcia, jak rejestracja, instalacja, tworzenie pierwszego dokumentu. W następnych krokach dodaliśmy go do systemu kontroli wersji oraz wspólnie utworzyliśmy pierwszego commita. W tej części postaramy się rozszerzyć nasz zakres działania o publikację repozytorium oraz pracę na nim w środowisku zdalnym.
Co to kontrola wersji i w jakim celu jej używać?
Najprościej mówiąc, kontrola wersji to proces polegający na zapisie stanu pliku w różnych etapach jego tworzenia. Wiele osób spotkało się z takim podejściem bez użycia żadnych narzędzi. Czy nie zdarzyło się wam zapisywać plików w podobny sposób?
- mójDokument.txt
- mójDokumentWersja2.txt
- mójDokumentSprawdzony.txt
- mójDokumentFinal.txt
Taki sposób zarządzania nazewnictwem i wersjami dokumentów to również kontrola wersji. Można przyjąć jakiś ustandaryzowany sposób nazywania plików, przykładowo dodając do ich nazw daty:
- mójDokument22-11-2021.txt
- mójDokument27-11-2021.txt
Choć taki system wydaje się łatwiejszy ,to nadal niesie ze sobą szereg problemów. Główną wadą takiego podejścia jest brak kontroli zmian w plikach pomiędzy ich wersjami. Bardzo prawdopodobnym jest, że zmiany były małymi poprawkami, jednak co w przypadku, gdy zmiany są rozległe i znacząco zmieniają chociażby strukturę całego pliku? A co jeśli w procesie tworzenia tego dokumentu rozmyślimy się na temat pewnych zmian i będziemy chcieli powrócić do wersji, która zawierała wszystko, co dotychczas, z wykluczeniem części zmian zaistniałych po drodze? W takich przypadkach możemy spędzić zdecydowanie zbyt wiele cennego czasu na doszukiwanie się odpowiedniej wersji naszego dokumentu.
Kontrola wersji adresuje problemy, które napotkaliśmy dotychczas, i szereg przypadków, o których nawet nie pomyśleliśmy, poprzez implementację systematycznego podejścia do dokumentowania zmian i zarządzania nimi w plikach. Przy pomocy narzędzi, takich jak tytułowy GitHub Desktop, jesteśmy w stanie zaopatrzyć nasze wersje pliku w informacje dotyczące tego, kiedy zostały one utworzone oraz jakich zmian dokonano pomiędzy wersjami. To pozwala w łatwy sposób na powrócenie do wariantu pliku, który nas interesuje. To niesie ze sobą szereg możliwości, o których w dalszych częściach artykułu.
Czy warto kontrolować zwykłe pliki tekstowe?
Ponieważ z plikami tekstowymi obcujemy nie tylko w zakresie pisania kodu, a chociażby badania wykorzystują szereg narzędzi cyfrowych i pamięć masową, powinniśmy zwrócić uwagę na zalety kontrolowania wersji i to, jak ważnym jest rozważne zarządzanie naszymi danymi. To wszystko staje się jeszcze ważniejsze, kiedy przychodzi nam współpracować z innymi ludźmi. Pomimo tego, że kontrola wersji została pierwotnie stworzona do obsługi kodu, korzystanie z niej w przypadku zwykłych dokumentów tekstowych niesie ze sobą wiele zalet. Jednymi z nich są:
- Śledzenie rozwoju i zmian w swoich dokumentach;
- Zapis zmian w taki sposób, który będzie zrozumiały w późniejszych etapach tworzenia;
- Eksperymentowanie z różnymi wersjami dokumentu zachowując oryginalną wersję;
- Połączenie ze sobą dwóch wersji dokumentu i rozwiązanie konfliktów pomiędzy nimi;
- Cofanie zmian, przenosząc się wstecz przez historię do poprzednich wersji.
Kontrola wersji jest szczególnie przydatna do ułatwienia współpracy z innymi osobami. Jednym z pierwotnych założeń takich systemów było umożliwienie różnym osobom wspólnej i równoległej pracy nad dużymi projektami. Jedną z ciekawostek jest fakt, że sam Git powstał w celu zarządzania kodem podczas rozwijania kodu źródłowego kernela systemu Linux. Używanie kontroli wersji do współpracy pozwala na większą elastyczność i kontrolę niż wiele innych rozwiązań.
Przykładowo, nad dokumentem mogą pracować dwie osoby w tym samym czasie, a następnie scalić ze sobą te dokumenty. W razie pojawienia się konfliktów system kontroli pozwoli Ci je zobaczyć i podjąć decyzję o tym, jak scalić te wersje z sobą, tworząc ostateczną wersję pliku. Dzięki temu zachowana jest również historia poprzedniej wersji — jeśli zechcesz wrócić do niej później.
Dobre praktyki nazewnictwa commitów i ich opisów
Ważnym jest, aby przy pracy z systemem kontroli wersji używać znaczących podsumowań i komunikatów commitów. Takie opisy wymagają wcześniejszego przemyślenia. Komunikaty, którymi opisujemy zmiany, mogą być zrozumiałe podczas commitowania, lecz czy będą one zrozumiałe dla innych lub dla samej osoby tworzącej commit po upływie jakiegoś czasu? Jeśli system kontroli wersji jest używany we współpracy z innymi, szczególnie ważne są dobre praktyki nazewnictwa, aby inne osoby mogły zrozumieć czego dotyczą utworzone commity.
Jednym z sposobów rozwiązania tego problemu jest próba zastosowania stylu commitów. Przyjęło się stosować dany format:
- Podsumowanie pisane wielką literą (50 znaków lub mniej),
- W razie potrzeby bardziej szczegółowy tekst objaśniający,
- Pisanie komunikatów w czasie teraźniejszym, przykładowo: “Fix problems” zamiast “Fixed problems”,
- Kolejne akapity po pustych wierszach,
- Bullet points.
Interfejs GitHub Desktop rozwiązuje niektóre z problemów związanych ze stylowaniem, ale dobrze jest być świadomym tego, w jaki sposób pisze się komunikaty commitów. Nie zawsze wymagane będzie pisanie obszernego tekstu, ale ważne jest, aby komunikat był jasny.
Budowanie sensownego repozytorium
Stopień korzyści, jakie czerpiemy z używania systemu kontroli wersji, w dużej mierze zależy od efektywnego korzystania z niego. Skupienie się zarówno na jasności komunikatów czy “atomowości” commitów znacznie ułatwi poruszanie się po repozytorium i przeglądanie różnych jego etapów w historii. Dobre repozytorium pozwoli łatwo zrozumieć zmiany, które zostały wprowadzone na różnych etapach, będzie zrozumiałe dla innych osób oraz pomoże zastanowić się nad zmianami, które wprowadzamy.
Istnieją różnice pomiędzy zarządzaniem repozytorium skupionym głównie na kodzie a repozytorium skupionym na zwykłym tekście. Jednakże oba repozytoria czerpią korzyści z przejrzystej i logicznej organizacji.
Publikacja twojego repozytorium
Na ten moment system kontroli wersji rejestruje nasze zmiany tylko lokalnie. Może to dla nas być wystarczające, jednak warto zastanowić się nad przesłaniem naszego repozytorium na GitHub, aby je upublicznić lub przechowywać poza naszym komputerem. Proces dokonania tego za pomocą GitHub Desktop jest prosty. Możemy to zrobić poprzez jego GUI. Spowoduje to wypchnięcie repozytorium z komputera do witryny GitHub i skonfigurowanie zdalnego repozytorium.
Po opublikowaniu repozytorium będzie ono widoczne na Twoim profilu na stronie GitHub. Możliwe jest skonfigurowanie prywatnego repozytorium, ale wymaga to zarejestrowania się jako student lub badacz albo opłacenia subskrypcji.
Gdy dokument zostanie opublikowany w GitHub, możemy nadal wprowadzać lokalne zmiany w pliku. Tym razem jednak wymagana będzie synchronizacja lokalnych zmian z tymi opublikowanymi w repozytorium. GitHub przechowuje zmiany zarówno lokalnie, jak i zdalnie.
Ważne jest, aby te zmiany były zsynchronizowane. W GitHub Desktop proces ten jest uproszczony poprzez użycie opcji synchronizacji zamiast używania poleceń push i pull w wierszu poleceń. Zapewni to, że lokalne i zdalne repozytoria będą takie same. Jeśli chcesz popracować nad swoim plikiem przed opublikowaniem go, możesz dokonać commitów bez synchronizacji. Umożliwi to wczesne zaimplementowanie kontroli wersji przy jednoczesnym zachowaniu zmian lokalnie na komputerze.
Dokonywanie zmian zdalnie
Jeśli chodzi o dokonywanie zmian, to mamy również możliwość dokonać ich zdalnie w repozytorium w interfejsie WWW.
Z interfejsu internetowego mamy do dyspozycji wiele opcji, w tym przeglądanie historii zmian, przeglądanie pliku w GitHub Desktop i usuwanie go. Na razie spróbujmy edytować plik w interfejsie internetowym i zsynchronizować te zmiany z naszym lokalnym repozytorium.
Klikamy opcję edycji, co pozwala nam na np. dodanie nowego tekstu.
Po dokonaniu zmian i zjechaniu w niższe partie strony zauważymy okno służące do dokonywania commitów.
Po zacommitowaniu tych zmian zostaną one zapisane w zdalnym repozytorium. Aby przywrócić je z powrotem na nasz komputer, musimy zsynchronizować te zmiany.
W ten sposób na naszym lokalnym repozytorium pojawią się zmiany dokonane przez nas zdalnie.
Na tym widoku możemy zauważyć tekst ze zmianami podświetlonymi na zielono i czerwono. Czerwony wskazuje, gdzie rzeczy zostały usunięte, a zielony wskazuje na rzeczy dodane. Jest to szczególnie przydatne w przeglądaniu zmian, które wprowadziliśmy przed dokonaniem commita, i pomaga stwierdzić, czy wszystkie z nich są zgodne z naszymi założeniami. Po lewej natomiast widzimy historię wprowadzonych zmian. W tej chwili ma ona zaledwie 3 wpisy, jednakże podczas pracy nad projektem będzie ich znacząco przybywać.
Rozwiązywanie konfliktów
Na konflikty natkniemy się, kiedy będziemy próbowali scalić lub zsynchronizować dwie wersje dokumentu ze zmianami, które są ze sobą sprzeczne. Jeśli będziemy ostrożni przy commitowaniu i synchronizowaniu zmian lokalnych, istnieje małe prawdopodobieństwo, że napotkamy ten problem. Jeśli mimo wszystko uda nam się stworzyć konflikt, to nie trzeba się obawiać, ponieważ można go rozwiązać w łatwy sposób.
Najbardziej prawdopodobnym jest, że konflikt pojawi się, kiedy dokonamy zmiany zdalnej, a następnie wprowadzimy kolejne zmiany na komputerze lokalnym bez uprzedniej synchronizacji zmian. Jeśli wprowadzimy zmiany w różnych częściach dokumentu, mogą one zostać scalone lub zsynchronizowane bez żadnych konfliktów. Jednakże mogą one ze sobą również kolidować.
Poniżej przeanalizujemy przykład, w którym mogą pojawić się konflikty, oraz przybliżymy, jak sobie z nimi radzić. Powiedzmy, że dodajemy zmianę do naszego zdalnego repozytorium na stronie GitHub.
Commitujemy tę zmianę na stronie internetowej, a następnie wprowadzamy zmiany lokalnie na naszym komputerze.
Jeśli spróbujemy w tym momencie zacommitować nasze zmiany, otrzymamy komunikat o niezsynchronizowanych zmianach:
Przy próbie pobrania zmian i synchronizacji dostaniemy komunikat o konfliktach:
Korzystając z edytora tekstu, takiego jak przykładowo Visual Studio Code, będziemy w stanie zauważyć nasz konflikt, otwierając plik. Git dodaje informacje o konfliktach do pliku w celu ich analizy i rozwiązania.
Niebieskim kolorem są oznaczone nadchodzące zmiany z repozytorium zdalnego. Natomiast zielonym kolorem są oznaczone zmiany, których dokonaliśmy lokalnie. Załóżmy, że nasze zmiany lokalne są tymi przez nas pożądanymi, więc bezpośrednio w edytorze możemy zaznaczyć opcję “Accept Current Change”, co spowoduje zaakceptowanie tylko zmian dokonanych przez nas lokalnie. Innymi możliwościami są “Accept Incoming Change”, co spowoduje zatrzymanie zmian jedynie z repozytorium zdalnego, oraz “Accept Both Changes”, które pozwoli na zachowanie obu ze zmian. Po rozwiązaniu naszego konfliktu i zapisie pliku, powracając do GitHub Desktop, otrzymamy komunikat o braku dalszych konfliktów.
To pozwoli na dokonanie scalenia. Podążając za instrukcją, powinniśmy teraz być w stanie wypchnąć zmiany, co zauważymy w historii repozytorium.
Podsumowanie i dodatkowe materiały
W niniejszym artykule przytoczyliśmy sobie podstawy na temat systemu kontroli wersji Git i korzystania z jego interfejsu graficznego GitHub Desktop. Systemy te posiadają o wiele więcej funkcji, których poziom skomplikowania zależy od tego, co próbujemy osiągnąć. Oprócz tego, co nauczyliśmy się w tytułowym artykule, poniższe zasoby pozwolą lepiej zrozumieć lub rozszerzyć swoją wiedzę na temat systemów kontroli wersji:
- GitHub zapewnia szerokie wsparcie w postaci poradników i pomocy,
- GitHub Glossary przybliży najczęściej używaną terminologię,
- Możemy skorzystać z płatnych kursów na platformie Udemy.
- Nasz poprzedni artykuł: GitHub - czym jest i jak z niego korzystać? Część 1.
