-
Notifications
You must be signed in to change notification settings - Fork 16
Podstawy git
Dokument w trakcie zmian!!!
Todo
- czym jest git i github
- idea kontroli wersji
- branche, forki
- Pracujemy na forku - opis jak założyć, o co chodzi
- new fork
- new branch
- commiting to the branch
- pull request do upstream
- jak aktualizować swój fork zmianami z głównego repo - rozpiska
Należy pobrać plik instalacyjny z https://git-scm.com/ skrót SCM (Source Code Manager) oznacza narzędzie do zarządzania wersjami kodu źródłowego.
I klikamy Next Next Next ...
I gratuluje masz zainstalowanego gita ;]
Na Windows zalecam używanie git bash
Git jest narzędziem które pozwala zarządzać, współdzielić wersje kodu oprogramowania. Git tak jak inne systemy dostępne poprzez internet potrzebuje serwera z którym mogą komunikować się klienci (czyli my). Git umożliwia utworzenie takiego repozytorium w którym znajdują się wyłącznie informacje o powstałych zmianach. Tak umieszczone repozytorium staje się naszym zdalnym repozytorium z którego mogą korzystać osoby w zespole. Problemem jest to że ktoś musiałby udostępnić swój serwer na takie repozytorium.
Tą właśnie potrzebę realizuje github. W skrócie github jest serwerem który hostuje zdalne repozytorium gita z którym mogą się łączyć wszystkie osoby które uczestniczą w projekcie. Github na tym nie poprzestaje i dodaje różne dodatkowe opcje które są związane z samym prowadzeniem projektu.
Ustaw informacje kim jesteś by każdy w zespole wiedział kto wykonał zmianę.
$ git config --global user.name 'Twoje imię i nazwisko lub pseudonim'
W celu wyświetlanie aktualnie ustawionej nazwy:
$ git config --global user.name
Dodatkowo ustaw jeszcze adres email
$ git config --global user.email twoj.adres@domena.com
W celu wyświetlenia aktualnie ustawionego adresu:
$ git config --global user.email
Masz już ustawionego gita, to teraz przejdź do katalogu w którym będziesz mieć repozytoria związane z projektami Data Workshop.
$ cd ~/projects/dw-projects
W przeglądarce otwórz repozytorium i kliknij zielony przycisk Clone or download. Kliknij ikonę kopiowania do schowka.
W git bash wpisz:
$ git clone https://github.com/dataworkshop/dw-cracow-project.git gdzie https://github.com/dataworkshop/dw-cracow-project.git zostało wklejone z schowka. Zostaniesz poproszony o swój username i hasło z githuba.
Lub
$ git clone https://username@github.com/dataworkshop/dw-cracow-project.git gdzie username to twój username z githuba a github.com/dataworkshop/dw-cracow-project.git zostało wklejone z schowka. Zostaniesz poproszony o swoje hasło z githuba.
krzys@DESKTOP-7UDV4G0 MINGW64 ~/projects/dev/py/dw-projects
$ git clone https://username@github.com/dataworkshop/dw-cracow-project.git
Cloning into 'dw-cracow-project'...
remote: Enumerating objects: 104, done.
remote: Counting objects: 100% (104/104), done.
remote: Compressing objects: 100% (83/83), done.
remote: Total 104 (delta 27), reused 48 (delta 6), pack-reused 0
Receiving objects: 100% (104/104), 40.44 KiB | 583.00 KiB/s, done.
Resolving deltas: 100% (27/27), done.
Repozytorium projektu zostało pobrane do ciebie na komputer i połączone z repozytorium zdalnym (na githubie).
Używając narzędzia do kontroli wersji pracujemy na gałęziach (branch) pierwszą gałęzią jest master to tu jest nasza główna wersja projektu. Do tworzenia nowej wersji, do pracy nad nową funkcjonalnością będziemy używać innych gałęzi które ostatecznie zostaną złączone z naszą główną gałęzią. Dzięki temu możemy mieć rozpoczętą pracę nad różnymi funkcjonalnościami lub różnymi wersjami tej samej funkcjonalności równocześnie nie zaburzając działania gałęzi głównej (mastera).
Do pracy z gitem można użyć wielu narzędzie graficznych, oto kilka z nich.
PyCharm posiada integracje z git. Tutaj możesz poczytać jak korzystać z Version Control w PyCharm
VS Code również posiada wsparcie dla git, szczegóły pod tym linkiem.
Popularnym narzędziem jest Git Kraken. Jest on osobnym programem który zajmuje się jedynie zarządzaniem repozytorium.
Starszym bratem dla Git Krakena jest Tortoise Git.
Można też pozostać przy git bash i bezpośrednio z jego pomocą wykonywać interakcje z repozytorium.
Kiedy już pobrałeś repozytorium będziesz musiał pobierać zmiany z repozytorium zdalnego w celu zachowania synchronizacji z zmianami jakie wprowadziły pozostałe osoby w zespole.
Do pobrania zmian służy komenda
$ git fetch
pobiera ona zmiany i prezentuje informacje o tym które gałęzie się zmieniły. Uwaga komenda ta nie powoduje natychmiastowego zaaplikowania tych zmian na twoje lokalne gałęzie.
Kiedy chcemy również pobrać informacje o gałęziach które zostały już usunięte używamy
$ git fetch --prune
Poleceniem które nie tylko pobierze informacje o zmianach ale również doda te zmiany do twojego lokalnego repozytorium jest:
$ git pull
W celu rozpoczęcia pracy nad nową wersją utwórz lokalną gałąź na której wykonasz zmiany i będziesz mógł przedstawić je reszcie zespołu w postaci pull requestu.
$ git checkout -b new-branch-name
W celu wyświetlenia listy zmienionych plików stosujemy
$ git status
a w celu zaprezentowania samych zmian
$ git diff
Po wykonaniu zmian trzeba dodać je do listy rzeczy które będą częścią nowej wersji (staging area)
$ git add . - dodaje wszystkie zmiany jakie git wyśledził do staging area
$ git add -p - uruchamia dodawanie zmian w formie interaktywnie, każda zmiana podlega osobnej decyzji
$ git commit - tworzy paczkę z naszych zmian znajdujących się w staging area jako pojedynczy przyrost wersji aplikacji
$ git commit -m "wiadomość" - działa jak poprzednia komenda ale umożliwia podanie komentarzu do przyrostu wprost z wiersza poleceń
$ git commit --amend - pozwala zmodyfikować ostatni przyrost, zarówno co do zmian zawartych w nim jak i wiadomości.
Gdy dodałeś jakąś zmianę za dużo czy też po prostu błędnie możesz zresetować stan staging area. Służy do tego
$ git reset @
@ która się tu pojawia oznacza najbardziej aktualny stan (wersja) względem lokalnego brancha. Można tu podać którego pliku reset ma dotyczyć.
Wersja z usunięciem zmian (przywróceniem poprzedniej wersji), używać rozważnie:
$ git reset @ --hard
Zdarzyć się może że przyrost który został utworzony należy wycofać, służy do tego:
$ git revert <commit> w miejscu <commit> należy wskazać który przyrost ma być cofnięty lub jaki zakres przyrostów.
Kiedy uznasz że nasza praca lokalna powinna znaleźć się na serwerze zdalnym wykonaj polecenia:
$ git push -u origin <nazwa gałęzi> - w miejscu <nazwa gałęzi> należy wskazać co chcesz wysłać na serwer zdalny. Tego polecenia użyj gdy po raz pierwszy wysyłasz zmiany i lokalna gałąź nie ma powiązania z gałęzią zdalną.
Kiedy wgrywasz kolejny stan do gałęzi która jest już u ciebie powiązana z serwerem zdalnym wystarczy zrobić:
$git push
Ważne by pamiętać że gdy na danej gałęzi nie pracujesz sam to przed wysłaniem należy pobrać zmiany znajdujące się na repozytorium zdalnym.
Przed sprawdzeniem stanu synchronizacji pobierz aktualny stan repozytorium zdalnego
$ git fetch --prune
A następnie wyświetl informacje
$ git branch -vv
* master 70ccfdb [origin/master] Update README.md
Gwiazdka * wskazuje aktualnie aktywną gałąź, następnie znajduje się nazwa gałęzi oraz najnowszy commit. W nawiasach [...] znajduje się informacja:
- nazwa zdalnej gałęzi jeśli istnieje
- informacja o różnicy pomiędzy wersją lokalną a zdalną, jeśli istnieje.
I na końcu jest komunikat ostatniego commitu.
Jeśli zmiany znajdują się zarówno na serwerze zdalnym jak i u Ciebie lokalnie to zmiany z serwera mają pierwszeństwo. W celu pobrania ich i zaaplikowania do swojej lokalnej gałęzi wykonaj:
$ git rebase origin/<nazwa gałęzi> komenda ta wstawi wszystkie brakujące zmiany pomiędzy twoje a część wspólną, jeśli pojawią się konflikty zostaniesz o tym poinformowany.
Rzeczą normalną są konflikty pomiędzy wersjami nad którymi pracuje się równolegle (na różnych gałęziach) należy sobie umieć z nimi radzić. Sam do rozwiązywania konfliktów używam narzędzi posiadających interfejs graficzny, najczęściej jest to narzędzie wbudowane w edytor kodu. Po rozwiązaniu konfliktu kontynuuj rebase:
$ git rebase --continue
Kiedy zakończyłeś pracę (lub chcesz skonsultować swoje zmiany), wysłałeś wszystkie zmiany na serwer zdalny przychodzi czas by podzielić się swoją pracą z resztą zespołu i zdecydować o włączeniu jej do gałęzi głównej (master). Z panelu pull requests można utworzyć nowy klikając przycisk New pull request. Następnie wybrać z której gałęzi zmiany mają być wysłane na master i kliknąć w Create pull request.
Poinformuj zespół że powstał nowy Pull request. Po pozytywnym przeglądzie taki request zostaje włączony do gałęzi głównej.
Ten krok nie jest konieczny ale uważam że łatwiej łączyć się poprzez ssh niż https. Jeśli wolisz podawać username i hasło do połączenia z git możesz pominąć ten krok.
Poniższe instrukcje zostały zaczerpnięte z oficjalnej strony github
Do dzieła:
-
Uruchom Git Bash.
-
Wykonaj (wklej) poniższe polecenie:
$ ssh-keygen -t rsa -b 4096 -C "twoj.adres@domena.com"
Generating public/private rsa key pair.
- Zostaniesz poproszony o podanie lokalizacji do zapisu: "Enter a file in which to save the key," wciśnięcie Enter spowoduje zapis w domyślnej lokalizacji.
Enter a file in which to save the key (/c/Users/you/.ssh/id_rsa):[Press enter]
- Możesz ustawić hasło zwiększając bezpieczeństwo (ale nie jest to wymagane)
Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]
Uruchomienie procesu ssh-agent
$ eval $(ssh-agent -s)
Dodanie klucza
$ ssh-add ~/.ssh/gh_win_rsa
Identity added: /c/Users/krzys/.ssh/gh_win_rsa (krzysztof@dudeksoft.pl)
- Zaloguj się na github.com
- Przejdź do ustawień
- Przejdź do SSH and GPG keys
- w git bash przejdź do katalogu w którym zapisałeś klucze
- odczytaj klucz publiczny $ less gh_win_rsa.pub
- skopiuj całość
- W github kliknij New SSH key
- Wprowadź nazwę która dobrze określa klucz oraz klucz
- Zatwierdź klikając Add SSH key
- Pod
/personal/username/każda osoba może trzymać swoje rzeczy które weryfikuje przed użyciem ich w kodzie głównym. W szczególności katalognotebooks. - Każdy tworzy swoje gałęzie robocze na których pracuje dopóki nie uzna że może wejść do brancha głównego (mastera)
- Pull request z notebooków nie wymaga przeglądu
- Pull request kodu głównego wymaga przeglądu i akceptacji przynajmniej jednej inne osoby