Opanowanie kontroli wersji: przewodnik dla początkujących

Wyobraź sobie, że pracujesz nad projektem oprogramowania i nagle wszystko idzie nie tak. Zmiany zachodzą na lewo, prawo i w środku, a Ty jesteś zagubiony w morzu kodu. W tym miejscu wkracza kontrola wersji. Wyobraź sobie taką sytuację: pracujesz nad projektem oprogramowania, może to twój pierwszy, może pięćdziesiąty, ale tak czy inaczej, jesteś po kolana w kodzie. Wprowadzasz zmiany, Twój zespół wprowadza zmiany i zanim się zorientujesz, próbujesz nawigować po oceanie modyfikacji bez kompasu.  Jest to przytłaczające, bałaganiarskie i po prostu mylące.

Kontrola wersji. To Twoje koło ratunkowe, ratownik, latarnia morska w burzy chaosu kodowania.  Zasadniczo kontrola wersji to system rejestrujący zmiany w pliku lub zestawie plików w czasie, dzięki czemu można później przywołać określone wersje.
To jak wehikuł czasu dla Twojego projektu, umożliwiający przeglądanie poprzednich wersji Twojej pracy, a nawet powrót do nich, jeśli to konieczne. Czy jesteś gotowy, aby zagłębić się w tę ratującą życie koncepcję kontroli wersji? Trzymajcie kapelusze, bo zaraz zdemaskujemy kontrolę wersji.

Typy Kontroli wersji

Skoro już przygotowaliśmy scenę, porozmawiajmy o typach systemów kontroli wersji. Istnieją dwa główne typy: scentralizowane i rozproszone.

Scentralizowane systemy kontroli wersji

Scentralizowane systemy kontroli wersji czyli CVCS, działają w jednym, centralnym repozytorium. Wszystkie zmiany i wersje przechowywane są w jednym miejscu, a każdy pracuje bezpośrednio z tym repozytorium.

Rozproszone systemy kontroli wersji

Z drugiej strony rozproszone systemy kontroli wersji, czyli DVCS, są nieco bardziej dynamiczne. Każdy użytkownik ma swoją kompletną kopię całego projektu, zawierającą wszystkie wersje i zmiany. Oznacza to, że jeśli serwer centralny ulegnie awarii w systemie DVCS, dowolne repozytorium użytkowników można skopiować z powrotem na serwer w celu jego przywrócenia.

Kluczowa różnica polega na konfiguracji repozytorium. W CVCS jest tylko jedno. W DVCS jest ich wiele. Każdy system ma swoje zalety, ale w tym filmie skupimy się na rozproszonej kontroli wersji, w szczególności na Git .

Ale po co zawracać sobie głowę kontrolą wersji?

Co w tym jest dla Ciebie? Cóż.

Kontrola wersji jest Twoim najlepszym współpracownikiem

Po pierwsze, kontrola wersji jest Twoim najlepszym współpracownikiem. Pozwala wielu osobom pracować nad projektem jednocześnie, bez deptania sobie nawzajem palców. Wyobraź sobie orkiestrę symfoniczną, w której każdy muzyk gra bezbłędnie swoją rolę, nie przeszkadzając sąsiadom. To właśnie robi kontrola wersji dla Twojego kodu.

Kontrola wersji to wehikuł czasu

Po drugie, kontrola wersji to wehikuł czasu. Śledzi każdą wprowadzoną zmianę, przez kogo i kiedy. Jeśli więc coś pójdzie nie tak, zawsze możesz cofnąć się w czasie do wersji, w której wszystko było niezłe.

Kontrola wersji jako zabezpieczenie

Na koniec pomyśl o kontroli wersji jako o zabezpieczeniu. Zapewnia kopię zapasową kodu, dzięki czemu, jeśli Twój komputer zdecyduje się wziąć nieoczekiwany urlop, Twoja ciężka praca nie pójdzie na marne. Zatem kontrola wersji działa jak superbohater, chroniąc Twój kod przed chaosem i zamieszaniem.

Git

Teraz poznaj Git , popularne narzędzie do kontroli wersji. Git to podstawowe narzędzie wielu programistów, jeśli chodzi o kontrolę wersji. Cóż, jego popularność wynika z zaawansowanych funkcji, elastyczności i solidnej wydajności.

Git to rozproszony system kontroli wersji. Oznacza to, że każdy programista pracujący nad projektem ma pełną kopię bazy kodu na swoim komputerze lokalnym. Pozwala to na szybsze operacje, dostęp offline i zindywidualizowane przestrzenie robocze. Piękno Gita tkwi w jego prostocie. Dzięki niemu śledzenie zmian, porównywanie różnych wersji i łączenie kodu z różnych gałęzi jest dziecinnie proste.

Git został zaprojektowany tak, aby szybko i efektywnie obsługiwać wszystko, od małych do bardzo dużych projektów. Niezależnie od tego, czy jesteś samodzielnym programistą pracującym nad pasjonującym projektem, czy częścią zespołu kodującego kolejną wielką rzecz, Git jest Twoim niezawodnym towarzyszem.
Dzięki Git zarządzanie kodem staje się bułką z masłem.

Gotowy na ubrudzenie sobie rąk Gitem?

Zacznijmy od instalacji Gita.
Można go pobrać z oficjalnej strony Git.

Po pobraniu postępuj zgodnie z instrukcjami wyświetlanymi na ekranie, aby zakończyć proces instalacji.

Teraz aby skonfigurować Twoje pierwsze repozytorium. Przejdź do katalogu, w którym chcesz umieścić swój projekt, i uruchom polecenie git init

Uruchom nowe repozytorium Git dla istniejącej bazy kodu

PRZYKŁAD

$ cd /path/to/my/codebase
$ git init      (1)
$ git add .     (2)
$ git commit    (3)

1. Utwórz katalog /path/to/my/codebase/.git directory
2. Dodaj wszystkie istniejące pliki do indeksu.
3. Zapisz nieskazitelny stan jako pierwsze zatwierdzenie w historii.

Spowoduje to utworzenie nowego repozytorium Git w tym katalogu. Teraz dokonajmy pierwszego zatwierdzenia. Ale najpierw utwórz plik. Możesz do tego użyć dowolnego edytora tekstu.

Po utworzeniu i zapisaniu pliku musisz dodać go do obszaru tymczasowego.
Zrób to, wpisując „git add nazwa pliku”.

Po przygotowaniu pliku nadszedł czas na zatwierdzenie.
Wpisz „ git commit -m Twoja wiadomość tutaj”.

Wiadomość powinna opisywać, co zmieniłeś. I masz to! Właśnie utworzyłeś nowy plik, przygotowałeś go i dokonałeś pierwszego zatwierdzenia.
Gratulacje! Właśnie dokonałeś pierwszego zatwierdzenia.

PRZYKŁAD

Przejdź do katalogu swojego projektu: Otwórz terminal i przejdź do głównego katalogu swojej istniejącej bazy kodów. To właśnie tutaj chcesz zainicjować repozytorium Git.

Zainicjuj repozytorium Git: Użyj komendy:

git init

Ta komenda tworzy nowy podkatalog o nazwie .git, który zawiera wszystkie niezbędne pliki repozytorium – szkielet repozytorium Git. W zasadzie ta komenda przekształca Twój istniejący katalog w repozytorium Git.

Dodaj wszystkie swoje pliki do repozytorium: Po zainicjowaniu repozytorium musisz dodać swoje pliki projektu do repozytorium, aby były śledzone. Użyj komendy:

git add .

Ta komenda dodaje wszystkie pliki w bieżącym katalogu do obszaru przygotowania (staging area), przygotowując je do zatwierdzenia (commit).

Zatwierdź pliki: Aby zapisać swoje pliki w repozytorium, musisz je zatwierdzić, dodając wiadomość opisującą zmiany. Użyj komendy:

git commit -m "Początkowe zatwierdzenie"

Ta komenda zatwierdza przygotowane pliki i dołącza wiadomość wyjaśniającą, co zostało zmienione.

[Opcjonalnie] Dodaj zdalne repozytorium: Jeśli chcesz wysłać swoje repozytorium do zdalnego serwera (takiego jak GitHub, GitLab, Bitbucket), musisz dodać zdalny adres URL:

git remote add origin [adres URL zdalnego repozytorium]

Następnie wyślij swoje zmiany do zdalnego repozytorium:

git push -u origin master

Zamień [adres URL zdalnego repozytorium] na adres URL Twojego zdalnego repozytorium. Flagę -u używa się do ustawienia źródła dla lokalnego repozytorium, co upraszcza przyszłe polecenia push i pull.

Sprawdź status swojego repozytorium: W każdej chwili możesz użyć komendy:

git status

Ta komenda pokaże Ci status Twojego roboczego katalogu i obszaru przygotowania. Może Ci to powiedzieć, czy są jakieś zmiany, które są przygotowane, nieprzygotowane lub nieśledzone.

Te kroki pomogą Ci przekształcić istniejącą bazę kodów w repozytorium Git i rozpocząć kontrolę wersji swoich plików. Pamiętaj, że częste zatwierdzanie zmian i z jasnymi wiadomościami to dobra praktyka w kontroli wersji.

Dodajmy więcej narzędzi do Twojego zestawu narzędzi Git .

1. git init
   • Użycie: git init
   • Opis: Inicjalizuje nowe repozytorium Git. Używane, gdy zaczynasz pracę z nowym projektem.
2. git clone
   • Użycie: git clone [URL]
   • Opis: Klonuje istniejące repozytorium Git z podanego URL.
3. git add
   • Użycie: git add [nazwa_pliku] lub git add .
   • Opis: Dodaje pliki do obszaru staging, przygotowując je do commitu. Używając git add ., dodajesz wszystkie zmodyfikowane pliki.
4. git commit
   • Użycie: git commit -m "opis zmian"
   • Opis: Zapisuje zmiany w repozytorium. Wiadomość commitu powinna opisywać dokonane zmiany.
5. git status
   • Użycie: git status
   • Opis: Wyświetla stan zmodyfikowanych plików, pokazując, które są gotowe do commitu i które jeszcze nie.
6. git push
   • Użycie: git push origin [nazwa_gałęzi]
   • Opis: Wysyła zmiany do zdalnego repozytorium. Na przykład, git push origin master wyśle zmiany do głównej gałęzi zdalnego repozytorium.
7. git pull
   • Użycie: git pull origin [nazwa_gałęzi]
   • Opis: Pobiera i łączy zmiany z zdalnego repozytorium do lokalnego repozytorium.
8. git branch
   • Użycie: git branch [nazwa_gałęzi] do tworzenia nowej gałęzi, git branch do wyświetlania listy gałęzi.
   • Opis: Zarządza gałęziami. Umożliwia tworzenie, listowanie i usuwanie gałęzi.
9. git checkout
   • Użycie: git checkout [nazwa_gałęzi]
   • Opis: Zmienia bieżącą gałąź na wybraną. Umożliwia przełączanie się między różnymi gałęziami projektu.
10. git merge
    • Użycie: git merge [nazwa_gałęzi]
    • Opis: Scala zmiany z wybranej gałęzi do bieżącej gałęzi.

Te komendy to podstawy, które umożliwiają efektywną pracę z systemem kontroli wersji Git. Jest to niezbędne narzędzie dla programistów i osób pracujących nad projektami wymagającymi śledzenia zmian w kodzie.

Oprócz podstawowych komend, istnieje wiele innych użytecznych poleceń Git, które mogą znacznie ułatwić pracę z kodem i zarządzanie repozytoriami. Oto kilka dodatkowych komend wraz z opisami:

1. git diff
   • Użycie: git diff lub git diff [nazwa_pliku]
   • Opis: Wyświetla różnice między plikami w obszarze roboczym a ostatnim commit. Pomaga zrozumieć, co dokładnie zmieniło się w kodzie.
2. git log
   • Użycie: git log
   • Opis: Wyświetla historię commitów w bieżącym repozytorium. Możesz zobaczyć, kto, kiedy i jakie zmiany wprowadził.
3. git reset
   • Użycie: git reset [commit_hash]
   • Opis: Pozwala cofnąć zmiany do określonego commitu. Używane do anulowania zmian, które nie powinny zostać zachowane.
4. git fetch
   • Użycie: git fetch origin
   • Opis: Pobiera wszystkie zmiany z zdalnego repozytorium, ale nie scala ich z bieżącą gałęzią. Pozwala sprawdzić zmiany przed ich scaleniem.
5. git rebase
   • Użycie: git rebase [nazwa_gałęzi]
   • Opis: Przenosi lub “rebazuje” bieżącą gałąź na wskazaną. Jest to alternatywa dla mergowania, pozwalająca na utrzymanie czystej historii projektu.
6. git stash
   • Użycie: git stash
   • Opis: Tymczasowo ukrywa zmiany w obszarze roboczym, pozwalając na przełączenie się między gałęziami bez konieczności commitowania nieukończonych zmian.
7. git tag
   • Użycie: git tag [nazwa_tagu]
   • Opis: Pozwala na oznaczenie określonych commitów jako ważne, na przykład wydania wersji. Tagi mogą być używane do oznaczania wersji wydanych produktów.
8. git remote
   • Użycie: git remote add [nazwa] [URL]
   • Opis: Zarządza zdalnymi repozytoriami. Pozwala na dodawanie, usuwanie i zmienianie adresów zdalnych repozytoriów.
9. git rm
   • Użycie: git rm [nazwa_pliku]
   • Opis: Usuwa pliki z obszaru roboczego i indeksu. Jest to sposób na usunięcie plików z repozytorium.
10. git blame
    • Użycie: git blame [nazwa_pliku]
    • Opis: Wyświetla, kto i kiedy dokonał zmian w każdej linii danego pliku, co jest przydatne przy szukaniu pochodzenia określonych zmian.

Te dodatkowe komendy pozwalają na bardziej zaawansowane zarządzanie kodem i repozytoriami, dając większą kontrolę nad procesem rozwoju oprogramowania.

Rozgałęzianie i łączenie (Branching and merging)

Rozgałęzianie i łączenie (Branching and merging) – brzmi skomplikowanie?

W świecie kontroli wersji rozgałęzianie przypomina tworzenie nowej piaskownicy, w której można się bawić, testować pomysły i tworzyć nowe funkcje bez zakłócania głównej bazy kodu. Pomyśl o tym jak o bezpiecznej strefie, w której możesz swobodnie eksperymentować. Teraz wyobraź sobie, że stworzyłeś przełomową funkcję w swojej branży i chcesz włączyć ją do głównej bazy kodu.

W tym miejscu pojawia się łączenie. Łączenie to czynność polegająca na zintegrowaniu zmian z gałęzi z powrotem z główną bazą kodu, dzięki czemu Twoje ulepszenia będą dostępne dla wszystkich.

 Jak to działa?

Krótko mówiąc, najpierw utworzysz gałąź, dokonasz zmian, a następnie połączysz te zmiany z powrotem z gałęzią główną. Jest to cykl, który utrzymuje główną bazę kodu w czystości i organizuje proces programowania. I tak po prostu nauczyliście się rozgałęziać i łączyć.

Konflikty (Conflicts)

Konflikty (Conflicts)– nie tylko w telenoweli.
Mogą się zdarzyć również w kodzie. Kiedy wielu programistów pracuje nad tym samym kodem, wprowadzone przez nich zmiany mogą czasami kolidować, co prowadzi do konfliktu.

Tutaj z pomocą przychodzi nasz system kontroli wersji Git . Wyobraź sobie dwóch programistów, Alicję i Boba, pracujących nad tym samym projektem. Alicja wprowadza zmiany w pliku, zatwierdza i wypycha swoje zmiany. W międzyczasie Bob również wprowadza zmiany w tym samym pliku. Kiedy Bob próbuje wypchnąć swoje zmiany, Git go powstrzymuje.

Dlaczego?

Ponieważ zmiany Alicji były pierwsze i Git nie chce ich nadpisywać zmianami Boba bez jasnej dyrektywy. Aby rozwiązać ten problem, Bob musi najpierw pobrać zmiany Alicji. Git spróbuje następnie scalić te zmiany. Jeśli Git nie może automatycznie scalić zmian, oznacza to konflikt.

Programiści muszą następnie ręcznie rozwiązać konflikt, decydując, które zmiany zachować. Po rozwiązaniu konfliktu Bob może ponownie zatwierdzić i wypchnąć zmiany. Konflikt rozwiązany! Teraz możesz poradzić sobie z każdym wyzwaniem związanym z kodowaniem, które stanie Ci na drodze.

Podsumowanie

Teraz, gdy już zasmakowałeś kontroli wersji, jesteś gotowy na podbój świata lub przynajmniej na kolejny projekt kodowania. Pomyśl o tym, co omówiliśmy.

Kontrola wersji to nie tylko narzędzie, to ratunek dla Twojego kodu. To jak wehikuł czasu, dzięki któremu możesz cofnąć się do dowolnego punktu w historii projektu, aby zobaczyć, jakie zmiany zostały wprowadzone, kto je wprowadził i dlaczego. Umożliwia śledzenie, zarządzanie i kontrolowanie zmian w bazie kodu , dzięki czemu współpraca jest płynna i wydajna.

Zbadaliśmy dwa główne typy systemów kontroli wersji: scentralizowane i rozproszone. Każdy z nich ma swoje mocne i słabe strony, ale pamiętaj , że wybór między nimi w dużej mierze zależy od potrzeb Twojego projektu i przepływu pracy Twojego zespołu.

Zagłębiliśmy się także w świat Gita , jednego z najpopularniejszych systemów kontroli wersji. Dotknęliśmy podstaw, od skonfigurowania repozytorium i dokonania początkowych zatwierdzeń initial commits, po zrozumienie ważnych poleceń, takich jak zatwierdzanie, wypychanie, ściąganie i rozgałęzianie. commit, push, pull, and branching.

Istnieje wiele platform hostingowych, takich jak GitHub , GitLab i Bitbucket , które zapewniają idealne środowisko dla Twoich projektów z kontrolą wersji. Oferują szereg funkcji współpracy, od przeglądu kodu po śledzenie błędów, co czyni je nieocenionymi narzędziami w zestawie narzędzi każdego programisty. Pamiętaj, każda podróż zaczyna się od jednego kroku.

Pierwszym krokiem na drodze do kontroli wersji jest rozpoczęcie jej używania w swoich projektach. Nie bój się popełniać błędów. W ten sposób się uczymy. Zastosuj się do tego procesu, a z biegiem czasu nabierzesz biegłości i będziesz się zastanawiać, jak kiedykolwiek kodowałeś bez niego. Wyruszając dalej, pamiętaj o najlepszych praktykach, które omówiliśmy.

Bądź sumienny w swoich komunikatach o zatwierdzeniach, strategiczny w swoich rozgałęzieniach i dokładny w przeglądach kodu. Te nawyki nie tylko ułatwią Ci życie, ale także poprawią jakość Twojego kodu i efektywność Twojego zespołu.

Zatem ruszaj i podbijaj swój kod za pomocą kontroli wersji. Masz to!