Git push – git integracja ze zdalnym repozytorium, git push, ssh, remote

Git push

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.

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

Git tutorial

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.

Git clone

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.

SmartGit fetch

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 

Git remote

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.

Git remote origin

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:

  1. Modyfikując plik konfiguracyjny: .git/config lub
  2. Przy pomocy komendy git remote remove

Git remove remote

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.

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!

  1. Pierwsze zdalne repozytoriumorigin – zostawimy tak, jak jest, czyli niech wskazuje na https://github.com/git/git
    Będziemy z niego tylko pobierać dane.
  2. Drugie repozytorium zdalne – nasze własne – nazwiemy „stormit” i skonfigurujemy do repozytorium na GitHub, które właśnie utworzyłem.

Github – git – StormIT

Git push origin

Prześledźmy jeszcze raz – krok po kroku, co tutaj zaszło:

  1. 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.
  2. git remote -v
    Od teraz mamy skonfigurowane dwa niezależne remote
  3. git push stormit
    Wysyłamy lokalne zmiany na remote „stormit”

Git 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.

Git push origin master

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.

Git branch

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 push new branch

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 list remote branches

Git pull remote branch

Załóżmy teraz, że chcemy pobrać zmiany ze zdalnego repozytorium z konkretnej gałęzi.

Uruchamiamy komendę: git pull stormit dev:

Git pull remote branch

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 pull remote branch 2
Git checkout remote branch

Spróbujmy teraz przełączyć się na jedną ze zdalnych gałęzi.

Zrobimy to jednak w kilku krokach:

  1. git status
    Mamy tutaj informacje o aktualnym stanie repozytorium i widzimy, że mamy jeden commit więcej w porównaniu z remote origin.
  2. git branch
    Lokalnie mamy dwie gałęzie – master i dev
  3. git branch -d dev
    Usuńmy na chwilę gałąź dev
  4. git checkout -b dev stormit/dev
    Przy pomocy tej komendy przełączymy się na zdalną gałąź stormit/dev oraz utworzymy lokalną gałąź dev
  5. git branch
    Jesteśmy już przełączeni na lokalną gałąź dev, która wskazuje na stormit/dev

Git checkout remote branch
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:

  1. git fetch origin (lub w naszym wypadku git fetch stormit) – pobrać zmiany ze zdalnego serwera
  2. 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 reset to origin
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.

  1. 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)
  2. git push stormit –delete dev – wysyłany usunięcie gałęzi dev na remote stormit
  3. git branch -d dev – usuwamy lokalną gałąź.

Git delete remote branch, Git remove remote branch

 

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


Jak zostać programistą

8 rzeczy, które musisz wiedzieć, żeby dostać pracę jako programista.

Jak zostać programistą
No comments
Share:

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *