Pokazywanie postów oznaczonych etykietą GIT. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą GIT. Pokaż wszystkie posty

piątek, 22 maja 2015

[GIT] Klonowanie repozytorium, zdalne repozytoria i klucze SSH

TRUE
7463796078999611238
Prawdziwą magią Gita jest możliwość współdzielenia kodu i praca zespołowa. W poprzedniej części nauczyliśmy się tworzyć własne repozytorium na lokalnym komputerze i pracy z nim, a teraz nauczymy się aspektów pracy z repozytoriami udostępnianymi przez innych programistów. Nauczymy się także w jaki sposób pracować na zdalnym repozytorium, hostowanym np. w serwisie GitHUB. Dowiemy się również na czym polega uwierzytelnianie i w jaki sposób tworzyć i korzystać z kluczy RSA, które będą wymagane np. do pracy z GitHUB-em.

Wiele projektów/aplikacji udostępnianych na licencji Open Source udostępnia swój kod w serwisach takich jak GitHUB (GIT), czy Google Code (SVN).
Wiele z takich projektów jest również w taki sposób rozwijanych, gdzie każdy chętny może dodawać swoje własne funkcjonalności, czy poprawki do czyjegoś kodu. Na czym polega sklonowanie repozytorium? W skrócie polega ono na sklonowaniu go ;) A dokładniej - na naszym dysku tworzona jest LOKALNA KOPIA repozytorium, na której możemy dowolnie pracować, a po skończonej pracy możemy wrzucić wszystkie stworzone lokalnie zmiany do oryginalnego, głównego repozytorium na serwerze, z którego dokonaliśmy sklonowania - jeśli oczywiście posiadamy takie uprawnienia.

Co jeśli takich uprawnień nie mamy? Bo przecież zapewne domyślamy się już, iż żaden programista nie pozwoli nam na dowolną modyfikację jego kodu bez jego zgody. Jak więc to wygląda w praktyce? Otóż - jeśli pracujemy na nie swoim repozytorium, to wszelkie zmiany, które dokonamy w kodzie lokalnie możemy osobie zarządzającej wysłać i zasugerować. Właściciel repozytorium, lub osoba uprawniona dostaje wtedy informację z żadaniem/prośbą dołączenia naszego kodu, np. z poprawkami do głównej gałęzi repozytorium. Może taką prośbę zignorować, albo zaakceptować zmiany jakie wprowadziliśmy i dołączyć naszą proponowaną gałąź do gałęzi głównej projektu.

A co jeśli pracujemy na swoim repozytorium, tyle że hostowanym na zdalnym serwerze, jak np. GitHUB?
Otóż w tym przypadku jako osoby uprawnione do pracy nad repozytorium (w końcu jest to nasze repozytorium) możemy pracować na nim dowolnie. Jak jednak wygląda sprawa "powiedzenia Gitowi", że mamy do danego repozytorium pełny dostęp? Otóż polega na zasadzie wymiany kluczy kryptograficznych. Rzecz polega na wygenerowaniu pary dwóch kluczy: klucza publicznego i klucza prywatnego. Klucz publiczny wysyłamy na serwer, na którym trzymamy nasze repozytorium np. na GitHUB-a, natomiast klucz prywatny trzymamy na swoim roboczym komputerze i pilnujemy ;) Następnie, w momencie połączenia przez SSH, pary kluczy są porównywane i na tej zasadzie określane jest, czy mamy dostęp do danego zasobu.
Kluczy oczywiście można dodać kilka - dla kilku osób, które będą miały uprawnienia do danego repo (jeśli pracujemy np. w teamie). O kluczach przeczytamy więcej kilka akapitów dalej.

Uwierzytelnianie może polegać też na zwykłym HTTPS, nie tylko za pomocą SSH.

czwartek, 21 maja 2015

[GIT] Podstawy i praca z repozytorium

TRUE
6335671948737500847
Git to obok Subversion drugi najpopularniejszy system wersjonowania kodu. Pozwala na bardzo przyjemną i przejrzystą organizację kodu zarówno dla pojedyńczego programisty, jak i w projektach wieloosobowych. Podstawy obsługi Gita są łatwe do ogarnięcia - wystarczy nauczyć się logiki działania takiego podejścia do wersjonowania projektu oraz zaznajomić się z kilkoma pojęciami, jakie spotykać będziemy podczas codziennej pracy z Gitem. W artykule tym postaram się w skrócie wyjaśnić na czym polega praca z repozytorium Gita i jak efektywnie wykorzystywać możliwości jakie daje on programiście. Artykuł pisany jest pod kątem pracy pod Windowsem, ale pod Linuxem składnia poleceń Gita jest identyczna, jedynie sposób instalacji jest inny.

Największą zaletą Gita jest to, iż zawsze pracujemy na lokalnej roboczy kopii naszego kodu, a nie na nim samym bezpośrednio. Jest to niesamowite rozwiązanie, bo po pierwsze pozwala na pracę "offline", po drugie sprawdza się to świetnie w pracy zespołowej, (o pracy w teamie i o tym jak to wygląda napiszę po krótce w innym tekście).

Jak więc działa Git? Zasada działania z początku może wydawać się zagmatwana, ale po zrozumieniu jej wyda się Wam banalnie wręcz prosta. W Gicie pracujemy z naszymi plikami w folderze roboczym. Pliki te mogą być śledzone przez Gita, lub nie. A co to znaczy "śledzone"? Znaczy to, że Git będzie je uwzględniał w swoim repozytorium i analizował wszelkie ich modyfikacje. Znaczy to też to, że pliki do repozytorium muszą być przez nas dodane.

Przyjrzyjmy się poniższemu diagramowi, który przedstawia możliwe statusy w jakich może znaleźć się każdy z plików naszego projektu:




webmaester.pl - profesjonalne projektowanie WWW i webaplikacji
webmaester.pl - profesjonalne projektowanie WWW i webaplikacji