Git jako najpopularniejszy rozproszony system kontroli wersji – pozwala na bardzo wydajną pracę zarówno ze zmianami przechowywanymi lokalnie, jak i z tymi znajdującymi się na zdalnym serwerze.
W ramach tego materiału dowiesz się jak pracować z Gitem i zdalnym repozytorium na przykładzie GitHub.
Spis treści
Git push – wprowadzenie
Z tego materiału dowiesz się:
- Jak pracować z Git i zdalnym repozytorium (remote)
- Jak zintegrować lokalne repozytorium Git z GitHub
- Jak działają takie operacje jak: git clone, git fetch, git pull oraz git push
Systemy kontroli wersji kodu źródłowego – Git
Systemy kontroli wersji odpowiedzialne są za śledzenie wszystkich zmian dokonywanych w plikach. Za ich pomocą można podejrzeć wcześniej dokonane zmiany oraz, w razie potrzeby, powrócić do starszej wersji pliku. Dzięki nim można również sprawdzić kto i kiedy dokonał tych zmian.
Obecnie Git jest najpopularniejszym rozproszonym systemem kontroli wersji. System pierwotnie został stworzony przez Linusa Torvalds jako narzędzie wspomagające rozwój jądra Linux i od tego czasu sukcesywnie zyskuje na popularności.
Git oficjalnie został wydany w 2005 roku i obecnie jest rozwijany na zasadach wolnej licencji – a co za tym idzie, swobodnie możemy go wykorzystywać w naszych projektach.
W ramach tego materiału zajmiemy się przede wszystkim pracą z Gitem i zdalnym repozytorium na przykładzie GitHub – natomiast kompletny tutorial Git znajdziesz poniżej.
➡ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone
Git install – Instalacja Git
Jeżeli nie masz jeszcze Gita zainstalowanego lokalnie – szybko możesz to nadrobić.
W poniższym materiale znajdziesz instrukcję, jak można to zrobić.
➡ ZOBACZ 👉: Install Git – Instalacja Git, Windows, Ubuntu – Bash, GUI
Git clone
Skoro wiemy już, po co jest nam system kontroli wersji i potwierdziliśmy, że git działa lokalnie – możemy przejść do kolejnego kroku, czyli sklonowania zdalnego repozytorium.
Sklonowanie repozytorium – to tak naprawdę pobrania zdalnego repozytorium na nasz lokalny komputer.
Przykładowa komenda:
git clone https://github.com/git/git
Przy pomocy komendy git clone pobieramy, prawie że idealną kopię (z pominięciem specyficznych serwerowych konfiguracji) zdalnego repozytorium na nasz lokalny dysk.
Taka kopia może służyć wręcz jako backup repozytorium – gdyby coś stało się z wersją przechowywaną na zdalnym serwerze.
Komenda git clone tworzy nam katalog z nazwą repozytorium – w tym wypadku jest to „git”.
Pamiętajmy o tym, gdy będziemy szukać naszych plików 😉
Od tego momentu – z pewnym przymrużeniem oka – można powiedzieć, że nasze lokalne repozytorium żyje własnym życiem.
Przykładowo – my lokalnie dokonujemy pewnych zmian na plikach, a jakiś inny deweloper w tym samym czasie również modyfikuje pliki znajdujące się w repozytorium (inne lub nawet te same pliki).
Jednak od czasu do czasu możemy chcieć zsynchronizować te zmiany.
Jeżeli chcemy pobrać najnowsze zmiany ze zdalnego repozytorium lokalnie – mówimy wtedy o operacji fetch (lub pull – o różnicach za chwilę).
Jeżeli natomiast chcemy wysłać nasze zmiany – mówimy o operacji git push.
Git fetch
Na starcie – warto podkreślić, że pobranie zmian ze zdalnego repozytorium oraz połączenie ich z lokalnym repozytorium – to dwie całkowicie niezależne czynności.
Polecenie git fetch origin pobiera wszystkie zmiany, których jeszcze nie było lokalnie.
Widać to dobrze na liście zmian w historii.
Zmiany z origin zostały już pobrane lokalnie, ale git nie zmodyfikował jeszcze lokalnej kopii repozytorium – lokalny branch master jest poniżej zdalnego origin/master.
Git merge
Żeby scalić zmiany wprowadzone przez innych użytkowników z naszymi, trzeba je jeszcze nanieść na lokalne repozytorium, np. przez merge:
git merge origin/master
W tym momencie może oczywiście dojść do konfliktów, jeżeli ktoś modyfikował ten sam fragment kodu co my – dla uproszczenia jednak pomińmy na chwilę ten przypadek.
Git pull
Powyższe dwa kroki (git fetch i git merge) zazwyczaj są wykonywane bezpośrednio po sobie, dlatego dla wygody – zostały połączone w jedną komendę:
git pull origin master
To polecenie jest równoznaczne z pobraniem najnowszych zmian z origin oraz zmergowaniem ich do lokalnego mastera.
Opcjonalnie można też zmodyfikować konfigurację gita i wykorzystać w tym miejscu git rebase zamiast git merge.
Git fetch vs pull
- git fetch – pobierze nam zmiany z origin – ale nie połączy ich z lokalnym repozytorium. To tak jakbyśmy tylko zerknęli, co się zmieniło – w żaden sposób nie wpływa to jeszcze na nasze lokalne zmiany.
- git pull – metoda pull pobierze nam też najnowsze zmiany oraz dodatkowo spróbuje połączyć je z lokalnymi.
Git remote
Skoro wiemy już, jak działa podstawowa komunikacja ze zdalnym repozytorium, to spróbujmy to trochę skomplikować 🙂
A trzeba przyznać, że zdecydowanie jest co komplikować… – bo np. git pozwala nam na pracę z więcej niż jednym zdalnym repozytorium jednocześnie!
Zacznijmy od wyświetlenia komendy:
git remote --help
Mamy tutaj listę dostępnych wszystkich opcji do zarządzania połączeniem ze zdalnymi repozytoriami.
Przyjrzyjmy się bliżej komendzie:
git remote -v
W ten sposób możemy sprawdzić, do jakiego zdalnego repozytorium jesteśmy połączeni.
Widzimy, że łączymy się do serwera o skróconej nazwie origin do tego samego adresu URL do operacji fetch i push.
Analogiczne informacje moglibyśmy sprawdzić, otwierając plik konfiguracyjny naszego repozytorium: .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = https://github.com/git/git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
Git remove remote
Zróbmy w takim razie kilka prostych ćwiczeń, które pomogą nam utrwalić tę wiedzę.
Zacznijmy od usunięcia remote (ang. git remove remote).
Możemy to zrobić na dwa sposoby:
- Modyfikując plik konfiguracyjny: .git/config lub
- Przy pomocy komendy git remote remove
W obu przypadkach uruchomienie komendy git remove -v powinna nam zwrócić pustą wartość.
Git add remote
Po usunięciu remote – straciliśmy jednak możliwość pobierania zmian ze zdalnego repozytorium 🙂
Dlatego spróbujmy teraz przywrócić tę konfigurację.
Tutaj również możemy zrobić to na dwa sposoby – modyfikując plik konfiguracyjny lub wywołując komendę git remote add.
To o czym warto jeszcze pamiętać, to to, że nasz lokalny branch master – niejako odłączył się od tego zdalnego.
Dlatego niezbędne będzie jeszcze przywrócenie fragmentu konfiguracji:
[branch "master"]
remote = origin
merge = refs/heads/master
Na samym starcie – bezpośrednio po wykonaniu komendy git clone nie musieliśmy tego robić, ponieważ nasze lokalne repozytorium automatycznie zostało połączone z tym, które klonowaliśmy.
Git push
Przyjrzyjmy się teraz bliżej kolejnej komendzie – czyli git push.
Dzięki operacji push – możemy niejako wypchać nasze zmiany na zdalny serwer.
Tutaj również może dojść do konfliktów – jednak i ten przypadek na ten moment pomińmy.
Git push GitHub
Ponieważ nie mamy uprawnień, żeby wysłać nasze zmiany do zdalnego repozytorium przechowującego kod źródłowy git (https://github.com/git/git) – zróbmy teraz coś odrobinę szalonego 😉
Skonfigurujemy nasze repozytorium, żeby mogło współpracować z dwoma zdalnymi repozytoriami jednocześnie!
- Pierwsze zdalne repozytorium – origin – zostawimy tak, jak jest, czyli niech wskazuje na https://github.com/git/git
Będziemy z niego tylko pobierać dane. - Drugie repozytorium zdalne – nasze własne – nazwiemy „stormit” i skonfigurujemy do repozytorium na GitHub, które właśnie utworzyłem.
Git push origin
Prześledźmy jeszcze raz – krok po kroku, co tutaj zaszło:
- git remote add stormit git@github.com:StormITpl/git.git
Dodajemy nowy remote o nazwie „stormit”, który wskazuje na nasz własny zdalny serwer. - git remote -v
Od teraz mamy skonfigurowane dwa niezależne remote - git push stormit
Wysyłamy lokalne zmiany na remote „stormit”
Wykonaliśmy operację git push stormit – czyli wypchaliśmy nasze zmiany do remote stormit.
W analogiczny jednak sposób moglibyśmy skorzystać z drugiego remote – czyli git push origin (gdybyśmy oczywiście mieli do niego odpowiednie uprawnienia).
Git push origin master
O ile pracujemy tylko z jedną gałęzią (ang. branch) master – sama operacja git push origin – wypchnie nam właśnie tę gałąź na zdalny serwer.
Czasami jednak pracujemy z większą ilością gałęzi i wtedy chcemy precyzyjniej określić, które dokładnie zmiany powinny zostać wysłane.
Git push branch
Ten przypadek – zacznijmy od utworzenia nowej gałęzi git, lokalnie w naszym repozytorium.
Uruchamiamy komendę git branch <nazwa-branch>, a następnie samo git branch, żeby wyświetlić listę lokalnych gałęzi.
Mamy dwie gałęzie:
- master – domyślna, oraz
- dev – świeżo utworzona.
Z czego master jest naszą aktualną gałęzią, na której teraz jesteśmy (oznaczona gwiazdką).
Git push new branch to remote branch
Możemy teraz uruchomić komendę: git push stormit dev, która:
- git push – wypchanie nam zmiany na zdalny serwer,
- stormit – na remote o nazwie „stormit”,
- dev – i zrobimy to dla brancha dev.
Git list remote branches
Mamy już teraz gałęzie lokalnie oraz zdalnie 🙂
Wyświetlmy je teraz, żeby się nie pogubić:
- git branch – lista gałęzi lokalnych
- git branch -r – lista gałęzi zdalnych
Git pull remote branch
Załóżmy teraz, że chcemy pobrać zmiany ze zdalnego repozytorium z konkretnej gałęzi.
Uruchamiamy komendę: git pull stormit dev:
O ile nie ma nowych zmian – powinniśmy zobaczyć komunikat w stylu „Already up to date.”
Jeżeli jednak będą jakieś zmiany, pobierzemy je wtedy.
Git checkout remote branch
Spróbujmy teraz przełączyć się na jedną ze zdalnych gałęzi.
Zrobimy to jednak w kilku krokach:
- git status
Mamy tutaj informacje o aktualnym stanie repozytorium i widzimy, że mamy jeden commit więcej w porównaniu z remote origin. - git branch
Lokalnie mamy dwie gałęzie – master i dev - git branch -d dev
Usuńmy na chwilę gałąź dev - git checkout -b dev stormit/dev
Przy pomocy tej komendy przełączymy się na zdalną gałąź stormit/dev oraz utworzymy lokalną gałąź dev - git branch
Jesteśmy już przełączeni na lokalną gałąź dev, która wskazuje na stormit/dev
Git reset to remote
Czasem podczas pracy nad lokalnymi zmianami zwyczajnie coś popsujemy 🙂
i chcemy wtedy przywrócić wszystkie zmiany ze zdalnego serwera.
Musimy wtedy:
- git fetch origin (lub w naszym wypadku git fetch stormit) – pobrać zmiany ze zdalnego serwera
- git reset –hard (w naszym wypadku konkretnie git reset –hard stormit/dev) – nadpisujemy wszystkie lokalne zmiany wskazaną gałęzią.
UWAGA! Ta komenda nadpisze wszystkie nasze lokalne zmiany – także ostrożnie z nią.
Git delete remote branch
Załóżmy teraz, że skończyliśmy już pracę na branchu dev i chcemy posprzątać po sobie – usuwając wszystkie niepotrzebne gałęzie.
- git checkout master
Przenosimy się na inną gałąź – w tym wypadku master – tak, żeby nie usuwać gałęzi na, której aktualnie siedzimy (jesteśmy) - git push stormit –delete dev – wysyłany usunięcie gałęzi dev na remote stormit
- git branch -d dev – usuwamy lokalną gałąź.
Git push – git integracja ze zdalnym repozytorium, git push, ssh, remote – podsumowanie
W ramach tego materiału przećwiczyliśmy podstawową integrację gita ze zdalnym repozytorium na przykładzie GitHub.
Jeżeli chcesz kontynuować swoją przygodę z gitem – to zapraszam do dodatkowych materiałów:
➡ ZOBACZ 👉: Git tutorial | stash, rebase, commit, merge, checkout, push i clone
20+ BONUSOWYCH materiałów z programowania
e-book – „8 rzeczy, które musisz wiedzieć, żeby dostać pracę jako programista”,
e-book – „Java Cheat Sheet”,
checklista – „Pytania rekrutacyjne”
i wiele, wiele wiecej!
