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ł

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

Dodawanie rozwiązania do git

Wybieramy Add to Source Control z paska statusu

przed

po

Publikowanie repozytorium

  • Team Explorer → Sync → Publish Git Repo

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

Git stages

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 zmian
  • fetch - pobieranie zmian (ale bez scalania)
  • pull = fetch + merge - pobieranie zmian i łączenie z lokalną kopią
  • sync = pull + push

Historia zmian

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


Porównywanie zmian w pliku

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

Tworzenie gałęzi

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

Scalanie gałęzi (merge)

merge - scalanie zmian z innej gałęzi do aktualnej 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

Ręczne scalanie konfliktów

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

  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

A successful Git workflow

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

Więcej informacji