Tut git

Tut git
1. Mamy repozytorium w necie
2. ’git clone <link do repo/ścieżka dostępu> <nazwa twojego repo → zostanie utworzony
foldero takiej nazwie w ./ >’
3. masz swoją wersję repo na kompie
4. poniewuż twoje repo to kopia czyjegoś, a nie stworzyłeś je za pomocą ’git init’, to git
zapisał sobie źródło (można znaleźć przez ’git config –get origin.master’ czy jakoś tak) to
przy ponownym ściąganiu nie piszesz znowu źródła(pkt.6)
5. Repo może mieć kilka gałęzi. Aktualna i domyślna to ’master’,
• tworzenie nowej to ’git branch <nazwa>’,
• przejście do innej to ’git checkout <nazwa gałęzi>’,
• potem się przechodzi z powrotem na ’master’ i wpisuje ’git merge <nazwa gałęzi, na
której się coś zmieniało>’, i to spowoduje włączenie zmian do gałęzi głównej
6. Ściąga się nowe rzeczy poleceniem ’git pull’ albo ’git fetch’, przy czym fetch nie zmienia
mastera
ogólnie ’git pull’ = ’git fetch’ + ’git merge’ jeśli masz własne repo, stworzone przez ’git
init’ to po ’git pull’ pisze się jeszcze ścieżkę dostępu do czyjegoś np. mastera
7. Jak zrobisz zmianę to możesz zobaczyć co to zmienia przez ’git diff’.
8. Aby to zapisać do listy zmian, którą się potem wykonuje na masterze to się piszę ’git
add <pliki, w których coś się zmieniło>’, zmiany teraz można podejrzeć przez ’git log -p
–current’
9. Zmiany do mastera zapisuje się poleceniem ’git commit’
• Wyskoczy ci edytor tekstu, żebyś wpisał komentarz tego commita, zamiast tego można dodać flagę -m i wpisać po poleceniu od razu
• jeszcze flaga -a pozwala pominąc wcześniejsze polecenie ’git add’
• ostatecznie pomijasz ’git add <pliki>’ i zostaje tylko ’git commit -am ”a tu jakiś
komentarz”’
10. Wysyła się na serwer poprzez ’git push’
1
11. w międzyczasie ktoś mógł coś na serwerze zmienić, wtedy zanim push czeba znowu pull
albo fetch+merge i tu mogą się pojawić konflikty. Jak kwestia jest tylko, że ktoś gdzieś
dodał albo usunął linijkę, w której nic nie zmieniłeś, to merge da rady automatycznie,
gorzej jak zmieniliście w tej samej linijce, wtedy merge zwraca błąd, dalej należy zrobić
commita swoich zmian, znowu merge, i tym razem git zrobi w konfliktowym pliku mniej
więcej taki coś:
>>>>>>>>>>>>>HEAD
tutaj jedna wersja, np. z publicznego
================
tutaj druga wersja, tzn chyba twoja
<<<<<<<<<<<<TU TEZ BYLY JAKIES WIELKIE LITERKI xD
No! Teraz usuwasz te linijki ze znaczkami <<<<,>>>>,==== i zostawiasz tylko jedną
z wersji → push, chyba, że znowu ktoś coś zmienił w tym miejscu, → pull i znowu leczenie
konfliktów.
Generalnie doszedłem do wniosku, że można stworzyć skrypt, który co sekunde coś pushuje,
co generalnie oznacza trolowanie reszty załogi i uniemożliwienie im jakiejkolwiek pracy z
gitem :P
2