TL;DR: GIT to sposób na zapisywanie postępów. Taki przycisk wstecz dla projektu. Wyjaśnienie podstaw działania oraz najważniejszych komend.

Warto zdać sobie sprawę, że jeśli idziesz do przodu z programowaniem to jest GIT. Jest też spoko, bo zarejestrowałem pierwsze oznaki życia na tym blogu. Cieszy mnie to mocno, bo wiadomo razem raźniej.

Ten tydzień jest pod znakiem GITa i na tym się skupię, bo muszę wam powiedzieć, że w następnym tygodniu wyjeżdżam i muszę sobie dawkować ten projekt tak, żebym dał radę to ogarnąć z ograniczonym dostępem do neta.

GIT w kilku słowach to sposób na zapisywanie zmian w plikach nad którymi pracujesz.

Dajmy na to, że pracujesz nad tajnyprojekt.txt to zamiast zapisywać kolejne kopie tego projektu jako ostatecznawersjatajnyprojekt2.txt, ostwerostatecznejwersjitajnyprojekt.txt i w bardzo krótkim czasie mieć milion kopii i pogubić się co jest czym, wystarczy użyć GITa, który ładnie będzie wszystkie zmiany dla ciebie przechowywał. ODYNIE! Dlaczego nie znałem tego pisząc magisterkę!

Coś jak przycisk „wstecz”

Tylko, że w tym przypadku dotyczy całego pliku a nawet projektu złożonego z kilku plików. Całkiem spoko, całkiem git.

Główna idea polega na tym, że git nie nadpisuje pliku tylko przechowuje wszystkie jego wersje. Jeśli coś się namieszało i chcesz wrócić do poprzedniej wersji, będzie to wyglądało tak:

wersja pierwsza >> wersja druga >> wersja trzecia >> wersja druga

Odgałęzienia/Kopie

Mało tego, można robić sobie odgałęzienia od głównego projektu. Dajmy na to wprowadzamy nową funkcjonalność, ale nie wiemy czy się sprawdzi i czy ją w ogóle użyjemy w finalnej wersji. Tworzymy wtedy tzw. branch czyli taką kopię i pracujemy na niej, nie martwiąc się o cały projekt. Jak stwierdzimy, że nowa funkcjonalność jest ok, możemy ją scalić (merge) z głównym projektem albo wrócić do wersji sprzed kombinowania.

Warto poznać

W tym tygodniu właśnie okiełznaniem GITa się zająłem. Wbrew pozorm nie jest to takie proste dla nowicjusza, ale zacząłem zauważać potencjał.

Zobacz. Masz dokumentację każdej najmniejszej zmiany jaką wprowadzisz do projektu wraz z notatką co i po jaką cholerę zrobiłeś.

Albo nad jednym projektem może pracować nawet kilka osób. Dajmy na to każdy ma inny pomysł na nową funkcjonalność. Każdy tworzy swój brach a na końcu najlepszy jest scalany (merge) z głównym projektem. Wszystko ładnie i przejrzyście.

GitHub to nie jest GIT, jest jakby przedłużeniem samego GITa, pozwala on wrzucać swój kod do sieci i dzielić się swoimi efektami pracy z innymi a nawet pozwolić im ulepszać go. Dlatego właśnie jest wymagany w tym konkursie. Takich miejsc do publikacji swoich repozytoriów jest więcej, ale tak się składa, że ten się dobrze przyjął wśród społeczności. Dla uproszczenia lepiej od razu ogarnąć jedno i drugie, bo ściśle się ze sobą łączą.

Całkiem sensownie to się zaczyna układać w całość. Zaczynam zauważać też plusy prowadzenia bloga. Przede wszystkim pozwala mi to usystematyzować moją wiedzę i dodatkowo może mi się przydać, gdy będę musiał wrócić do czegoś co już przerabiałem.

Czarny Olek, nie jest łatwo tłumaczyć, szczególnie jak się samemu dopiero poznaje nowe rzeczy. Poniżej znajdziesz moje notatki z tego tygodnia, ale jeśli szukasz merytorycznych materiałów dotyczących GITa to lepiej zajrzyj tutaj. Jeśli jednak to źródło jest dla ciebie równie nudne jak dla mnie obejrzyj lepiej to:

możesz też zajrzeć tu, tutaj lub tu.

Hej! A może znasz jakieś przydatne funkcje GITa? Może znasz jakieś tips and tricks? Daj znać w komentarzu. Dzięki za wsparcie!

Moje notatki:

Najważniejsze komendy do GITa

sudo apt-get install git-all

Instalacja GITa na Ubuntu odbywa się w terminalu.

TIP: Żeby wkleić skopiowany tekst do terminala wciskamy Ctrl+Shift+V

git config

Konfiguracja. Trzeba podać nick i maila.

Te dwie komendy używamy tylko raz przy zakładaniu tego całego bałaganu. Pod spodem komendy, których będziemy używać częściej.


git init 

Inicjalizacja repozytorium (miejsce w którym zapisują się zmiany) w katalogu w którym się znajdujemy.

git remote add origin https://github.com/username/repozytorium.git

Ustawianie konkretnego repozytorium jako głównego do którego będą wysyłane (push) zmiany. „Orgin” można zamienić na dowolną nazwę.

Dodawanie zmian w plikach odbywa się w 3 krokach.

1. git add nazwapliku.txt / git add .

Dodawanie pliku / wszystkich plików do commita (czyli do takiej poczekalni)

2. git commit -m „Opis zmian”

Dodawanie opisu do commita

LUB git commit -a -m „Opis zmian” żeby zrobić to za jednym zamachem. UWAGA: w ten sposób nie dodamy nowych plików do repozytorium. Działa to tylko na plikach, które już wcześniej były dodane.

3. git push

Wysyłanie zmian do GitHuba

git status

Sprawdzamy w jakim stadium są zmiany

git reset HEAD nazwapliku.txt

Cofanie pliku z commita przed wysłaniem. Patrz wyżej – doszedłeś do pkt. 2 ale zamiast wysłać do GitHuba cofasz się do pkt. 1

git log

Patrzymy jakie zmiany zostały dokonane

git checkout 08bd2 — nazwapliku.txt

Cofanie do konkretnego commita, gdzie 08bd2 jest początkiem nazwy commita (nie trzeba wpisywać całości)

git checkout nazwapliku.txt

Cofanie do ostatniego commita (ostatniej zapisanej zmiany)


git branch nazwanowegobranchu

Tworzenie jakby dodatkowej kopii/odgałęzienia na której możemy działać w ramach GITa bez mieszania w głównych plikach, np. gdy chcemy dodać nową funkcjonalność, ale nie wiemy czy to wszystkiego nie wykrzaczy.

git checkout nazwa

Uaktywniamy pracę na odgałęzieniu/pobocznej kopii. To jest mega przydatne, bo można za jednym przełączeniem wrócić do poprzedniej działającej wersji projektu we wszystkich plikach jednocześnie. Wystarczy wpisać np. git checkout master i wrcamy do głównej wersji projektu.

git push origin nazwanowegobranchu

Wysyłanie zmian do GitHuba w ramach innego branchu niż master. Można ustawić ten nowy branch jako domyślny git push -u origin nazwanowegobranchu

git merge nazwanowegobranchu

Jak skończymy pracę nad nową funkcjonalnością i chcemy ją dodać do głównego projektu to zespalamy go tą komendą. Najpierw jednak musimy wrócić do głównej kopii projektu git checkout master


Plik .gitignore

Można tam wrzycić nazwy wszystkiego tego, czego nie chcemy żeby GIT nam commitował. Zwykły plik tekstowy a zaszczędzi wrzucania różnych śmieci do projektu, które czasem się tworzą. Np. plików, które tworzy nam IDE. Tutaj więcej.

Usuwanie śmieci

np. niechcianego pliku lub folderu, który wpadł już do commita, tu na przykładzie foldera „.idea”

1) z obecnej wersji repozytorium:


git rm .idea
git commit -am "Remove IDE files"
git push

2) Z całej historii (gdy chcemy usunąć wszelkie ślady – to raczej używamy w ostateczności)


git filter-branch --tree-filter 'rm -rf .idea' --prune-empty HEAD
git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d
git commit -m 'Removing .idea from git history'
git gc # garbage collection
git push origin master --force

5 uwag do wpisu “Jest GIT

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google

Komentujesz korzystając z konta Google. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Połączenie z %s