Git – kilka słów o systemie kontroli wersji

Projekt się tworzy, ba… Nawet już jest wrzucony pierwszy commit. Powiesz, że nic tam nie ma? No nie ma, nic od siebie jeszcze nie dodałem, ale za to przygotowałem jak umiałem repozytorium do pracy. Mało odkrywcze? Pewnie tak – znajdziesz to i na stackoverflow i na stronie gita, ale przejść przez to trzeba, więc dlaczego by tego nie opisać?

Jeśli tworzyłeś już jakiś projekt wspólnie ze znajomymi czy pracujesz już zawodowo to pewnie otarłeś się o jakikolwiek system nadawanie wersji kodu. Opcji jest sporo. Można wysyłać sobie kod mailem – szalony pomysł, czyż nie? Albo wrzucać wszystko na Google Drive i za każdym razem myśleć o tym, kto, co i kiedy zdążył podmienić w pliku. Można też skorzystać z dedykowanych systemów kontroli wersji jak git czy SVN. Z tym drugim nie miałem jeszcze okazji pracować, natomiast gita wykorzystywałem w kilku projektach – czasem z sukcesem a czasem modląc się, żeby wyszło tak jak miało wyjść. Nawet, jeśli pracujesz nad projektem sam, a kod nie musi być dostępny publicznie to warto zastanowić się nad kontrolą wersji. Dzięki odpowiedniemu wykorzystaniu systemów tego typu można nie tylko mieć pewność, że kod będzie przechowywany w bezpiecznym miejscu nawet, jeśli maszyna na której pracujesz ulegnie awarii, ale też łatwo wrócić do poprzedniej wersji projektu czy też podejrzeć systematyczność własnej pracy obserwując kolejne commity.

Git to system kontroli wersji, projekt jest open-source, darmowy w użyciu. Sam git tworzy repozytorium i pozwala na jego zmiany, jednak, aby dzielić się kodem z innymi potrzebny jest jeszcze hosting tak utworzonego repozytorium. W Internecie możesz znaleźć różne strony, które oferują przechowywanie kodu. Sam korzystam zarówno z Githuba jak i z BitBucketa – ten drugi pozwala na tworzenie prywatnych repo bez opłat, co w pewnych przypadkach, gdy nie chcemy chwalić się całemu światu kodem projektu, jest pomocne.

W projekcie Familiada będę korzystał z Githuba, takie wymagania postawił organizator. Repozytorium projektu możesz znaleźć pod tym adresem.

Ok. Więc jak zacząć? Zacznijmy od stworzenia nowego repozytorium na Githubie. Proces jest prosty, wybierzmy New repository i uzupełnijmy wszystkie pola w formularzu. Na dole możemy wybrać czy chcemy dołączyć plik o rozszerzeniu .gitignore i licencję do naszego projektu. Licencjom poświęcę jeszcze jeden post, bo sam mam niewielką wiedzę na ich temat i chętnie ją usystematyzuję.

Plik .gitignore służy do tego, aby powiedzieć systemowi kontroli wersji, które pliki z tych, które będą w folderach projektu są niepotrzebne w repozytorium. Wykorzystanie tego pliku pozwoli na odchudzenie przesyłanych i przechowywanych na serwerze informacji. Osobiście z rozpędu przy tworzeniu repozytorium przy zgłoszeniu projektu pominąłem ten punkt, ale jeśli tworzyłbym je jeszcze raz to dzięki dodanym możliwością na początek wygenerowałbym plik .gitignore z opcją Visual Studio, ponieważ pierwszą częścią projektu będzie tworzona przy pomocy tego narzędzia aplikacja WPF. Jeśli nie dodamy tego pliku teraz to nic straconego! Możemy go dodać w dowolnym momencie, a z pomocą może przyjść na przykład strona www.gitignore.io.

Plik .gitignore zawiera po prostu wymienione rozszerzenia lub ścieżki folderów, które należy pomijać przy dodawaniu pliku do repozytorium, tak, aby nie trzeba było ręcznie tego kontrolować. Najbardziej potrzebne fragmenty, jeśli nie używamy dodatków do VS to początkowe linijki.

[code]
# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
bld/
[Bb]in/
[Oo]bj/
[Ll]og/
[/code]

Dzięki odchudzeniu projektu o foldery powstające w fazie budowania projektu przez Visual Studio będziemy mieli w repo tylko pliki niezbędne do odpalenia lub zbudowania aplikacji. Podobnie pozbywamy się zaciągniętych przez VS paczek z NuGeta, które VS przygotuje sobie samo, w przypadku, gdy nie odnajdzie ich w folderach projektu na komputerze.

Mamy już utworzone repozytorium na Githubie. Teraz czas zainicjalizować je na lokalnym komputerze. Po pierwsze musisz zainstalować Gita na swojej maszynie. Swoją kopię pobrałem z oficjalnej strony. Przy instalacji wybrałem opcję Use Git bash only ponieważ i tak jestem przyzwyczajony do używania tej właśnie konsoli do operowania Gitem.

Po instalacji przejdź do folderu gdzie chcesz utworzyć folder projektu. Z menu kontekstowego wybierz opcję Git Bash here. Otworzy się konsola Gita i będzie można zacząć pracę.

Komenda clone wywołana jak poniżej spowoduje sklonowanie zawartości repozytorium z Githuba na dysk komputera.

[code]
git clone https://github.com/MDikkii/test1.git
[/code]

Po przejściu do utworzonego folderu zobaczyć można tam plik README, LICENSE i .gitignore o ile utworzyłeś je w procesie tworzenia repozytorium. I to w zasadzie tyle – repozytorium już tu jest. Utworzyłem plik tekstowy o nazwie test.txt, żeby zademonstrować jak zapisywać zmiany.

Komendą git status możesz podejrzeć stan. Po dodaniu pliku wyświetli się on jako untracked file – nie jest dodany do repozytorium. Wpisz git add . (kropka dodaje wszystko co jest w folderze projektu do repo). Tym razem plik jest zielony i nad nim znajduje się napis świadczący o tym, że plik zostanie dodany do bazy repozytorium. Aby to zrobić wywołaj komendę git commit –m „test commit”. Flaga –m pozwala na dodanie wiadomości dołączonej do commitu.

Po tym zostaje nam tylko przeprowadzić komendę push, co spowoduje przekazanie commitów do repozytorium na Githubie.

We wpisie pokazałem tylko najprostszą ścieżkę pracy z gitem, przed rozpoczęciem pracy warto przeczytać artykuły na oficjalnej stronie gita. Jeśli podczas procesu tworzenia repozytorium napotkasz jakieś problemy to w Internecie prawdopodobnie znajdziesz rozwiązanie swoich rozterek. W dalszej części projektu spróbuję podzielić się moimi doświadczeniami z pracy z repozytorium, w przypadku jednoosobowego projektu pewnie nie będzie spektakularnych problemów z wersjami plików i ich łączeniem, ale chętnie pokaże narzędzie TortoiseGit, którego używam w innych projektach między innymi to ułatwienia sobie pracy przy łączeniu różnych wersji jednego pliku.