Git w Visual Studio
Jak utworzyć repozytorium git?
Różne sposoby
- repozytorium w Azure Repos, zdalne, powstaje przy tworzeniu projektu w Web Portal
- istniejące repozytorium (zdalne, lokalne) można sklonować
(np. z GitHub, Azure Repos) - automatyczne tworzenie repozytorium dla nowych projektów w Visual Studio
- tworzenie repozytorium dla istniejącego projektu w VS
Klonowanie repozytorium z Azure DevOps
- Team Explorer → Manage Connections → Connect to Project → Clone
Źródło: https://docs.microsoft.com/en-us/azure/devops/repos/git/
Klonowanie z innych źródeł
- Team Explorer → Local Git Repositories → Clone
- adres repozytorium (zdalne lub lokalne)
- ścieżka katalogu lokalnej wersji repozytorium
Konfiguracja repozytorium
- ustawienia globalne dla wszystkich repozytoriów (np. Imię, Nazwisko i email programisty)
Team Explorer → Settings → Global settings - ustawienia lokalne - specyficzne dla danej kopii repozytorium (np. adres zdalny repozytorium)
Team Explorer → Settings → Repository settings
Konfiguracja adresów
- Fetch adres źródłowy pobierania zmian
- Push adres docelowy wysyłania zmian
- origin domyślna nazwa zdalnego repozytorium
Najważniejsze komendy
- add: dodanie nowego pliku do rewizji (śledzenie zmian)
- commit: zatwierdzenie zmian - powstaje nowy węzeł w repozytorium (lokalnie)
- push wypchnięcie zmian do zdalnego repozytorium
- pull pobranie zmian i scalenie z lokalną kopią
- tworzenie i scalanie (merge) gałęzi
- cofanie zmian (revert), przywracanie poprzednich stanów (reset)
- przeglądanie i porównywanie zmian w kodzie
commit: zatwierdzanie zmian
- Team Explorer → Changes lista zmian oczekujących na zatwierdzenie
- commit - zatwierdzenie zmian
- zmiany muszą być opatrzone opisem
Synchronizacja ze zdalnym repozytorium
push
- wypchnięcie zmianfetch
- pobieranie zmian (ale bez scalania)pull
=fetch
+merge
- pobieranie zmian i łączenie z lokalną kopiąsync
=pull
+push
Cofanie zmian
- Undo changes - wycofywanie niezatwierdzonych zmian
- Revert - cofanie zatwierdzonych zmian, nie zmienia historii ale tworzy nowy commit,
- Reset - przywraca historyczną wersję repozytorium.
Nie należy używać na współdzielonych z zespołem gałęziach
Gałęzie (branches)
- gałęzie zawierają równolegle rozwijane wersje kodu, pomiędzy którymi możemy w prosty sposób się przełączać (checkout)
- master domyślna nazwa głównej gałęzi
Konflikty
- łączenie kodu odbywa się automatycznie jeżeli to możliwe
- konflikt, gdy ta sama linia została zmieniona w osobnych gałęziach i automatyczne scalenie nie jest możliwe
- może wystąpić przy operacji pull, sync, merge
Rozwiązywanie konfliktów
- Take source - nadpisz zmianami ze źródłowej gałęzi
- Keep Target - nadpisz zmianami z docelowej gałęzi
Pull request
Po wysłaniu zmian umieszczonych w osobnej gałęzi możemy poprosić członków zespołu o weryfikację kodu i dodanie do głównej gałęzi
Typowy workflow
Źródło: https://www.atlassian.com/blog/bitbucket/5-pull-request-must-haves
- tworzymy nową gałąź (nowa funkcja, naprawa błędu, …)
- zmieniamy zawartość nowej gałęzi i zatwierdzamy zmiany (commit)
- gdy praca skończona wysyłamy gałąź do zdalnego repozytorium (push)
- składamy prośbę (pull request) o weryfikację kodu i integrację z główną gałęzią
- gdy zmiany zostaną przyjęte, wówczas aktualizujemy lokalną kopię ze zmianami, które mogli nanieść inni użytkownicy, rozwiązujemy konflikty
Więcej informacji
- Git i GitLab w Visual Studio by Jacek Matulewski