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

https://docs.microsoft.com/en-us/azure/devops/repos/git/

Team Explorer -> Local Git Repositories -> Clone

adres repozytorium (zdalne lub lokalne)

ś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

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

http://nvie.com/

Azure Repos Git Documentation

git - fast version control

Git i GitLab w Visual Studio by Jacek Matulewski