Jak korzystać z Gita? Poradnik podstawowy

Data dodania: jakiś czas temu
reklama

git

Git to system kontroli wersji, co już pewnie zdążyłeś przeczytać na niejednej stronie. W tym poradniku skupimy się na konkretach podstaw Gita, zgodnie z maksymą tego bloga 🙂

Ale mimo wszystko słowo wstępu się należy. Choć Git został stworzony głownie po to, by ułatwić pracę nad jednym projektem kilku osobom, przyda się on także i programistom pracującym solo. Zatem zabierzmy się do dzieła i poznajmy podstawowe polecenia Gita!

Co robi Git?

Git dba o to, by każdy uczestnik projektu miał zawsze jego najnowszą wersję. Git należy do rozproszonych systemów kontroli wersji, a więc oprócz tego, że projekt jest na serwerze, to każdy z uczestników projektu ma swoją lokalną wersję u siebie. Zatem jeśli serwer szlag trafi, to nic złego nie powinno się stać. Git potrafi sobie radzić także z takimi sytuacjami, jak edycja tego samego pliku przez dwie osoby. System po prostu postara się połączyć wprowadzone zmiany i jednej i drugiej osoby. Co więcej, Git przechowuje wszystkie wersje danego pliku, dlatego jeśli coś się popsuje, nie ma problemu by odzyskać poprzednią wersję. Dlatego chociażby dlatego warto używać Gita nawet jeśli pracuje się solo.

Ok super, to jak zacząć?

Osobiście polecam korzystać z Gita w wersji tekstowej (z konsoli). Działa to również pod systemem Windows. Wystarczy pobrać obsługę Git stąd. Po instalacji wystarczy odpalić Git Bash i już mamy włączoną konsolę Gita.

No to jedziemy! Ale zaraz, skąd wziąć serwer?

Oprócz serwerów, które możemy postawić sobie sami, istnieją jeszcze 2 bardzo popularne i darmowe serwery Git. Jednym z nich jest bardzo popularny Github. Jednak ograniczeniem Githuba w wersji darmowej jest to, że projekt musi być Open Source, czyli o otwartym źródle. Natomiast jeśli chcemy założyć sobie darmowe, niejawne, prywatne repozytorium polecam skorzystać z Bitbucket.org. Serwis ten pozwala bezpłatnie postawić sobie własne repozytorium dla maksymalnie 5 użytkowników przy danym projekcie. Zatem wybierzcie swój serwer i załóżcie na nim swój pierwszym projekt, czyli tzw. zdalne repozytorium.

Repozytorium na serwerze gotowe, czas przygotować pierwszy projekt do wysyłki

Czas na część właściwą. Na początek odpalamy konsolę Git czyli Git Bash. Teraz za pomocą komend konsoli musimy przejść do katalogu, w którym trzymamy nasz projekt. Dla przypomnienia podaję najważniejsze polecenia:

cd .. - przeniesienie do katalogu wyżej
cd nazwakatalogu - wejście do danego katalogu

Jeśli zaczniecie pisać nazwę danego katalogu i wciśniecie TAB konsola automatycznie powinna wypełnić pozostałą część nazwy folderu. Bardzo przydatne 🙂

Jesteście już w swoim katalogu? Ok, zatem wpisz następujące komendy:

git config --global user.name "Twoje imię i nazwsko"
git config --global user.email twój@email
git init

Pierwsze 2 polecenia zapisują w Git informacje o twórcy wszystkich projektów tworzonych na danym komputerze (ze względu na dopisek –global). Robimy to tylko raz, chyba, że chcecie to później zmienić.

Ostatnie polecenie inicjuje powstanie repozytorium i to ono nas najbardziej interesuje. Komenda po prostu tworzy odpowiednie foldery Gita w projekcie. Foldery te są ukryte i normalnie ich nie widać. Git init używamy przy tworzeniu danego projektu. Jeśli kiedyś będziecie tworzyć nowy projekt w innym folderze, wtedy powtórzycie ten krok już tylko z komendą git init.

Teraz musimy dodać nasz serwer, na którym zarejestrowaliśmy swój pierwszy projekt. Robimy to następującym poleceniem

git remote add twoja-nazwa-zdalnego-repozytrium git://adres-twojego-serwera/nazwa-repozytorium.git

Serwer dodany. Listę wszystkich dodanych serwerów dla danego projektu można sprawdzić następującym poleceniem:

git remote -v

Wysyłamy!

Ok, starczy gadania. Wyślijmy w końcu ten projekt. Najpierw musimy powiedzieć Gitowi, które pliki chcemy dołączyć do repozytorium. Domyślnie dodaje się wszystkie pliki i katalogi w danym folderze, więc najczęściej stosuje się polecenie:

git add *

Po dodaniu wszystkich plików musimy jeszcze zatwierdzić zmiany w projekcie, służy do tego polecenie commit. Wpisz commit -h by poznać wszystkie warianty dla tego polecenia, chociażby z ciekawości. My użyjemy natomiast tego:

git commit -m 'nazwa commita'

Jako nazwa commita możemy wpisać cokolwiek co odnosi się do wprowadzonej przez nas zmiany. Np. pierwsze pliki, poprawka błędów, dodanie czegoś itd. Teraz kiedy mamy już dodane pliki i zatwierdzone zmiany, możemy je w końcu wysłać na serwer. Robimy to przy pomoce tego polecenia:

git push twoja-nazwa-zdalnego-repozytrium master (dodawaliśmy serwer nieco wyżej, jakby ktoś zapomniał :))

Poleceni push „wypycha” dane na serwer. Dopisek „master” mówi Gitowi, że wypychamy swoją główną gałąź projektu, czyli po prostu projekt główny. O gałęziach w dalszej części artykułu. Git zadba o to, by przy wykonywaniu „pusha” posiadać aktualną wersję projektu. Inaczej nie pozwoli nam na „wypchnięcie” plików.

No i gotowe. Właśnie udało Ci się wysłać swój pierwszy projekt na serwer Git!

Pobieranie aktualnej wersji projektu z serwera

Jeśli przyszło Wam pracować w kilka osób, aktualną wersję projektu pobierzecie następującym poleceniem:

git fetch twoja-nazwa-zdalnego-repozytorium

lub


git pull twoja-nazwa-zdalnego-repozytorium

Zarówno jedna jak i druga komenda pobiera aktualną wersję. Różnią się tym, że „pull” dodatkowo stara się połączyć zmiany, które mogły się pojawić u nas, zanim zdążyliśmy je wysłać na serwer. Dlatego osobiście używam właśnie „pull”.

Cofanie zmian

Czasami zdarza się, że musimy cofnąć wprowadzone zmiany, bo zwyczajnie projekt szlag trafił i przestał działać. Tutaj Git też nam pomoże. Możemy się cofnąć się do dowolnego commita. Listę commitów możemy sprawdzić następująco:

git log

Wyświetli nam się lista commitów wraz z ich hashem (to te niezrozumiałe ciągi znaków). Załóżmy, że mamy taki oto commit, do którego chcemy się cofnąć:

commit as213h9732yq34338hdnao9u324312
Author: Jan Kowalski
Date: jakaś data

Ostatni super commit

By cofnąć się do tej zmiany wpisujemy:

git reset --hard as213h9

Za słowem „–hard” wystarczy podać tylko kilka pierwszych znaków hasha. Git sam rozpozna, o którą zmianę nam chodzi.

Branch czyli gałąź projektu

Git umożliwia nam i innym tworzenie kilku wersji tego samego projektu. W Gicie nazywa się to branchem, czyli gałęzią projektu. Przydaje się to np. gdy chcemy przetestować dwie różne zmiany tego samego pliku lub całej grupy tych samych plików. Git domyślnie pracuje na gałęzi głównej, czyli master. Bez problemu możemy jednak dodać nowe gałęzie:

git branch testy

Właśnie utworzyliśmy gałąź testy. By się na nią przełączyć, wpisujemy:

git checkout testy

I już jesteśmy na nowej gałęzi. Jeśli w pewnym momencie stwierdzimy, że warto połączyć obie gałęzie, wykorzystamy do tego polecenie:

git merge nazwa-galezi

Listę wszystkich gałęzi dostępnych projekcie wyświetlimy za pomocą:

git branch

Gałąź aktualna będzie oznaczona gwiazdką (*) przy nazwie. A jak usunąć niepotrzebną nam gałąź? A no bardzo prosto, wystarczy wpisać:

git branch -d nazwa-galezi-do-usuniecia

Kilka innych pomocnych komend

Zebrałem dla Was jeszcze kilka innych pomocnych komend, które mogą Wam się kiedyś przydać:

git clone git://nazwaserwera/nazwaprojektu.git - klonuje, czyli kopiuje repozytorium prosto na Twój dysk twardy

git status - pokazuje aktualny status plików

git push nazwa-zdalnego-serwera nazwa-galezi --force - wymusza wysłanie na serwer Waszej wersji projektu nawet jeśli są one niezgodne. Nie polecam używać o ile to możliwe

Te najczęściej stosuje się razem:

git fetch --all
git reset --hard origin/master

– wywołanie tych dwóch komend sprawi, że zostanie pobrana wersja repozytorium prosto z serwera usuwając Twoją lokalną wersję danego repozytorium. Może się przydać w przypadku, gdy wersja nasza lokalna jest niezgodna z tą na serwerze i chcemy zrezygnować z naszych zmian pobierając aktualną „wersję serwerową”.

Baza wiedzy

Na temat Gita powstało wiele źródeł wiedzy. Jeśli chcecie zgłębiać Gita dokładniej, odsyłam Was tutaj. Miłego czytania!


PS. jeśli masz konto na Facebooku, polub fanpage Konkretnego. Dzięki!




Tagi: , , , , , , , , , ,

Bądź miły! Uwielbiam wchodzić z Wami w dyskusję, proszę jednak, by krytyka była konstruktywna. Komentarz, który ma na celu obrażać mnie lub moich Czytelników może zostać usunięty. Tutaj każdy ma czuć się dobrze :)

  • Bardzo przyzwoicie napisany artykuł. Konkretnie i na temat 🙂 Mam tylko jedno pytanie odnośnie wysyłania zmian na serwer. Mianowicie chcę, aby zmiany które „push’ne” na Bitbucket jednocześnie opublikowały się na moim serwerze FTP. W jaki sposób mogę coś takiego zrobić?

    • Nie wiem czy na bitbucket uda się ten efekt osiągnąć. Kiedyś admin w firmie, w której pracowałem zrobił taką sztuczkę, że pushe na odpowiedni branch wysyłały także pliki na FTP, ale wtedy Git był na serwerze firmowym pod pełną kontrolą admina.

      Natomiast znalazłem coś takiego (ale nie testowałem): https://github.com/git-ftp/git-ftp 🙂

      • Szczerze mówiąc myślałem, że to podstawowa funkcja Bitbucket, żeby to właśnie tak działało 🙂 Szkoda, że tak nie jest. Przetestuję w takim razie „Git-ftp”, natknąłem się też na to wcześniej, ale chciałem użyć tego w ostateczności :p Dzięki za odpowiedź! Pozdrawiam

        • Bitbucket to po prostu serwer Git z obsługą za pomocą strony WWW. Z gitem można czynić różne rzeczy, ale jest głównym zadaniem jest przede wszystkim kontrola wersji plików aplikacji 🙂

Jestem także tutaj


YouTube - ostatni film z Filek.TV

YouTube - ostatni film z Konkretny.pl

Discord

Chcesz ze mną pograć?
Wbijaj na mój Discord

Partnerzy











O blogu

Konkretny.pl to blog technologiczny, którego tematyka porusza kilka specjalistycznych dziedzin. Jednymi z najważniejszych są zagadnienia dotyczące technologii i Internetu, ale nie brakuje tutaj również typowych tekstów dotyczących finansów, marketingu, programowania, a nawet gier komputerowych. Życzę przyjemnej lektury :)


Social Media

 



© 2011-2018 Marcin Romanowicz. Wszelkie prawa zastrzeżone.

Wszystkie posty piszę w dobrej wierze. Nie odpowiadam jednak za wszelkie szkody, treść komentarzy oraz autentyczność informacji na stronie. Informuję, że publikowane pliki zostały sprawdzone programem antywirusowym w aktualnej wersji. Nie biorę jednak odpowiedzialności, jeśli coś się stanie.

| O mnie |   | Polityka Prywatności |   | Kontakt |