Git w Visual Studio

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

• Team Explorer → Manage Connections → Connect to Project → Clone

<fs x-small>Źródło: https://docs.microsoft.com/en-us/azure/devops/repos/git/</fs>

1. Team Explorer → Local Git Repositories → Clone
2. adres repozytorium (zdalne lub lokalne)
3. ścieżka katalogu lokalnej wersji repozytorium

Wybieramy Add to Source Control z paska statusu

przed

po

• Team Explorer → Sync → Publish Git Repo

• 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
  

• Fetch adres źródłowy pobierania zmian
• Push adres docelowy wysyłania zmian
• origin domyślna nazwa zdalnego repozytorium

• 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

• ** Team Explorer** → Changes lista zmian oczekujących na zatwierdzenie
• commit - zatwierdzenie zmian
• zmiany muszą być opatrzone opisem

• push - wypchnięcie zmian
• fetch - pobieranie zmian (ale bez scalania)
• pull = fetch + merge - pobieranie zmian i łączenie z lokalną kopią
• sync = pull + push

• historia zmian - każda zatwierdzona zmiana tworzy węzeł w repozytorium

• 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 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

• Team Explorer → Branches → New Local Branch From….

merge - scalanie zmian z innej gałęzi do aktualnej gałęzi

• łą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

• Take source - nadpisz zmianami ze źródłowej gałęzi
• Keep Target - nadpisz zmianami z docelowej gałęzi

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

<fs x-small>Źródło: https://www.atlassian.com/blog/bitbucket/5-pull-request-must-haves</fs>

1. tworzymy nową gałąź (nowa funkcja, naprawa błędu, …)
2. zmieniamy zawartość nowej gałęzi i zatwierdzamy zmiany (commit)
3. gdy praca skończona wysyłamy gałąź do zdalnego repozytorium (push)
4. składamy prośbę (pull request) o weryfikację kodu i integrację z główną gałęzią
5. gdy zmiany zostaną przyjęte, wówczas aktualizujemy lokalną kopię ze zmianami, które mogli nanieść inni użytkownicy, rozwiązujemy konflikty

<fs x-small>Źródło: http://nvie.com/ </fs>

• Azure Repos Git Documentation
• git - fast version control
• Git i GitLab w Visual Studio by Jacek Matulewski