→ Slide 1

Git w Visual Studio

→ Slide 2

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
→ Slide 3
  • Team ExplorerManage ConnectionsConnect to ProjectClone

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

→ Slide 4
  1. Team ExplorerLocal Git RepositoriesClone
  2. adres repozytorium (zdalne lub lokalne)
  3. ścieżka katalogu lokalnej wersji repozytorium

→ Slide 5

Wybieramy Add to Source Control z paska statusu

przed

po

→ Slide 6
  • Team ExplorerSyncPublish Git Repo
→ Slide 7
  • 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

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

→ Slide 9
→ Slide 10
  • 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
→ Slide 11
  • Team ExplorerChanges lista zmian oczekujących na zatwierdzenie
  • commit - zatwierdzenie zmian
  • zmiany muszą być opatrzone opisem
→ Slide 12
  • push - wypchnięcie zmian
  • fetch - pobieranie zmian (ale bez scalania)
  • pull = fetch + merge - pobieranie zmian i łączenie z lokalną kopią
  • sync = pull + push
→ Slide 13
  • historia zmian - każda zatwierdzona zmiana tworzy węzeł w repozytorium


→ Slide 14

→ Slide 15
  • 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
→ Slide 16
  • 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

→ Slide 17
  • Team ExplorerBranchesNew Local Branch From….

→ Slide 18

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


→ Slide 19
  • łą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

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

→ Slide 21

→ Slide 22

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

→ Slide 23

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

  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
→ Slide 24

Źródło: http://nvie.com/

→ Slide 25