Udostępnij za pośrednictwem

Zrozumienie, jak polecenia Team Foundation Version Control (TFVC) są odwzorowywane na przepływy pracy Git

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

informacji o wersji Visual Studio 2019 | informacji o wersji Visual Studio 2022

Czy planujesz wdrożyć Git, czy znasz się na działaniach TFVC i zastanawiasz się, jak mają się one do Gita? Oba są zaawansowanymi i dojrzałymi systemami kontroli źródła. Jednak mapowanie typowych czynności, do których się przyzwyczailiśmy, w jednym na drugie, może być mylącym doświadczeniem.

Ten artykuł nie zagłębia się w polecenia Git, ponieważ są one dobrze udokumentowane w dokumentacji produktu, ale przedstawia przykłady, które pomogą w podjęciu właściwych decyzji podczas przechodzenia przez typowy przepływ pracy składający się z faz: tworzenia, klonowania, tworzenia gałęzi, wprowadzania zmian, zatwierdzania i wypychania.

Zacznij od początku, tworząc nowe repozytorium

Każdy projekt może hostować repozytoria TFVC i Git w tym samym projekcie, tworząc jeden serwer TFVC i co najmniej jedno repozytoria Git.

Tworzenie nowego repozytorium Git w usłudze Azure Repos

Po utworzeniu repozytorium zostaną wyświetlone instrukcje krok po kroku, aby szybko rozpocząć pracę.

Rozpocznij pracę z nowym repozytorium Git w Azure Repos

Kliknij opcję Utwórz plik ReadMe na końcu strony z instrukcją, aby zapewnić kontekst repozytorium i stworzyć jego historię.

Tworzenie pliku README w celu zainicjowania nowego repozytorium Git w usłudze Azure Repos

Utwórz obszar roboczy i pobierz najnowszą wersję

Podczas nawiązywania połączenia z repozytorium TFVC po raz pierwszy zazwyczaj tworzysz obszar roboczy i uzyskujesz najnowszy kod. jak rozpocząć pracę w usłudze Git?

Podobnie jak w przypadku obszaru roboczego w programie TFVC, repozytorium Git clone sklonuj do folderu na maszynie. Klonowanie spowoduje pobranie całej zawartości i historii repozytorium na komputer lokalny. Po sklonowaniu repozytorium, prawie wszystkie operacje są wykonywane lokalnie. Możesz pracować w trybie offline z pełną kopią zapasową scentralizowanego repozytorium.

git clone https://dev.azure.com/demo-fabrikam/Fabrikam/_git/Mapping-TFVC-actions-to-Git

Wystarczy sklonować repozytorium tylko raz, ale podobnie jak w przypadku obszarów roboczych TFVC, możesz mieć wiele jego klonów, aby odizolować pracę w toku. Jednak rozgałęzianie jest zazwyczaj lepszym sposobem odizolowania zmian.

Tworzenie gałęzi

W Git zawsze pracujesz w gałęzi, a domyślnie w domyślnejmain gałęzi. Zalecamy utworzenie wielu gałęzi lokalnych. Jest to proces, który zajmuje kilka sekund i umożliwia bezproblemowe przełączanie kontekstu między różnymi gałęziami projektu oraz pracę w środowisku izolowanym. W przeciwieństwie do gałęzi TFVC, które są ograniczone do ścieżek, gałęzie Git obejmują cały repozytorium. Są lekkie, mogą być tylko lokalne lub udostępniane innym osobom, kiedy będziesz gotowy do udostępnienia zmian.

Rozważ rozgałęzianie, jeśli musisz pracować w izolacji, zawiesić swoją pracę, skoncentrować się na nowych funkcjach lub jeśli planujesz przeprowadzić prośbę o scalenie w Git.

Jako użytkownik TFVC powtórz kilka razy:

  • Zalecane jest rozgałęzianie!
  • Rozgałęzianie usługi Git jest niedrogie, szybkie i zaawansowane!
  • Usługa Git zachęca do korzystania z gałęzi lokalnych .
  • W razie potrzeby opublikuj lokalne gałęzie w scentralizowanym repozytorium.
  • Przed wprowadzeniem zmian zawsze weryfikuj kontekst gałęzi.
  • Nazwij gałąź przy użyciu wspólnej konwencji, takiej jak users/alias/branchname, na przykład: users/doris/newfeature

Utwórz i przełącz się do lokalnej gałęzi tematu o nazwie francis/demo-feature. Dobrym rozwiązaniem jest najpierw uruchomienie git status, aby sprawdzić, czy jesteś na właściwej gałęzi na początek.

git checkout -b francis/demo-feature

Tworzenie nowej gałęzi Git z poziomu wiersza polecenia systemu Windows

Wprowadź zmianę, dodając pliki

Podobnie jak w przypadku środowiska kontroli wersji serwera Team Foundation, nowe pliki w folderze roboczym nie są automatycznie częścią repozytorium. Możesz przygotować nowe pliki przy użyciu polecenia git add, co jest równoznaczne z wykonywaniem operacji add Items to Folder w programie TFVC.

git add <file>

lub

git add --all

Korzystając ze wstępnie przygotowanego przykładu, będziesz mieć 13 nowych plików, które zostały dołączone i przygotowane w repozytorium lokalnym.

Wyświetlanie oczekujących zmian

Zastanawiasz się, jakie zmiany są teraz obecne w środowisku roboczym? Tak jak wcześniej, polecenie Git status lub widok Changes w środowisku IDE programu Visual Studio pokaże zmiany w drzewie roboczym.

git status

Wyświetlanie zmian etapowych przy użyciu stanu usługi Git

Zaewidencjonuj zmiany i zatwierdź lokalnie

W programie TFVC zmiany są udostępniane przez polecenie 'Check In', które wysyła oczekujące zmiany na serwer. Proces Git jest trochę inny. Najpierw należy zatwierdzić repozytorium lokalne, utworzyć obiekt zatwierdzenia (na przykład zestaw zmian), a następnie wypchnąć te zmiany na serwer.

Zmiany w repozytorium lokalnym są zatwierdzane przy użyciu polecenia git commit, podobnie jak Checkin Pending Changes w programie TFVC. Kluczową różnicą jest to, że git commit zatwierdza zmiany w repozytorium lokalnym zamiast repozytorium zdalnego .

git commit

Zaewidencjonuj zmiany za pomocą serwera/repozytorium zdalnego

Najpierw należy opublikować lokalną gałąź francis/demo-feature na serwerze zdalnym, który zawiera wszystkie zatwierdzone zmiany.

git push --set-upstream origin francis/demo-feature

Aby zsynchronizować dalsze aktualizacje w środowisku lokalnym z repozytorium zdalnym, należy wypchnąć zmiany przy użyciu polecenia git push. Zalecaną praktyką przy użyciu polecenia git lub środowiska IDE programu Visual Studio jest:

  • fetch aby pobrać zawartość i wyświetlić podgląd zmian przychodzących od innych.
  • pull aby pobrać, a następnie scalić zmiany z innych.
  • push aby udostępnić zmiany lokalne.

Wyświetl historię

Aby zobaczyć zatwierdzenie, które właśnie utworzyłeś, możesz przejrzeć historię lokalną.

W przypadku kompaktowej historii użyj:

git log --oneline

Aby uzyskać szczegółowy widok, użyj:

git log

Przeglądanie historii gałęzi przy użyciu dziennika git

Jak pokazano powyżej, git log wymienia autora, adres e-mail, datę zapisu i sumę kontrolną SHA-1 zatwierdzenia. Jako użytkownik TFVC możesz skorzystać z opcji --stat, aby dołączyć więcej informacji, takich jak nazwa pliku i statystyki zmiany.

Historię scentralizowanego repozytorium można również wyświetlić przy użyciu portalu internetowego usług Azure DevOps Services.

W portalu internetowym usługi Azure DevOps Services wybierz > lub KOD Eksplorator Historia

Wyświetlanie historii gałęzi w usłudze Azure Repos

W tym momencie pomyślnie zbadałeś przepływ pracy — tworzenie -> klonowanie -> gałąź -> zmiana -> zatwierdzanie -> wypychanie , oparty na typowych akcjach TFVC.

Istnieje również możliwość wystawienia pull request, aby opublikować i przygotować zmiany na serwerze/repozytorium zdalnym w tym momencie.

Inne akcje

Przełączanie gałęzi

Podczas pracy z usługą Git nie zmieniasz gałęzi, przełączając się na oddzielne foldery i lokalizacje na maszynie. Kontekst można zmienić, wykonując checkout, dzięki czemu cały katalog roboczy odpowiada wybranej gałęzi lub zatwierdzeniu. Szybkie i proste!

Wiersz polecenia

git checkout <branch>

Jeśli nie pamiętasz gałęzi znajdujących się w repozytorium lokalnym, użyj polecenia git branch , aby wyświetlić listę domyślnych i znanych gałęzi.

Pamiętaj, nad którą gałęzią pracujesz! Podczas pracy z wieloma gałęziami w usłudze Git przełączasz gałęzie w tym samym katalogu roboczym. Przełączanie między gałęziami jest szybką operacją i upewnienie się, że jesteś we właściwej gałęzi przez cały czas, jest dobrym rozwiązaniem.

Pobierz najnowszą wersję

Istnieje wiele powodów, dla których warto pobrać aktualizacje. Jeśli na przykład musisz przełączyć kontekst do innego projektu, odśwież maszynę dewelopera przy użyciu najnowszej wersji bazy kodu.

Wiersz polecenia

git pull

lub

git fetch

Następuje

git merge FETCH_HEAD

Zawsze pobierz najnowszą wersję i rozwiąż konflikty scalania lokalnie.

Cofnij zmiany lokalne

Może istnieć prawidłowa przyczyna przywrócenia wszystkich poprawek w repozytorium lokalnym i zresetowania środowiska roboczego do najnowszej wersji z repozytorium zdalnego.

Wiersz polecenia

git reset --hard HEAD

Następuje

git pull origin

Następuje

git clean -xdf

Scenariusz jest podobny do wykonywania Get > Latest Version z opcjami Overwrite writable files that are not checked out i Overwrite all files if the local version matches the specified version w TFVC.

Alternatywnie możesz ręcznie usunąć repozytorium lokalne — oczywiście po utworzeniu zweryfikowanej kopii — a następnie ponownie clone repozytorium.

Użytkownikom usługi Git jest dostępnych o wiele więcej akcji i opcji. Poniżej przedstawiono kilka przydatnych witryn referencyjnych do dalszego czytania:

Pytania i odpowiedzi

Co z synchronizacją?

Commit and Sync, możesz zadać sobie pytanie.

Wybierz pozycję Git>Commit lub Stash, aby otworzyć Zmiany Git. Wybierz menu rozwijane Commit All (Zatwierdź wszystko), a następnie wybierz pozycję Commit All and Sync (Zatwierdź wszystko i synchronizuj).

Możesz też w programie Team Explorer wybrać menu rozwijane Zatwierdzenia, a następnie polecenie i synchronizację.

Zatwierdzanie i synchronizowanie w programie Team Explorer

Z magią przychodzi odpowiedzialność! Wielu użytkowników nie lubi sync tego, ponieważ czasami może psuć lokalną historię i dodać zatwierdzenie scalania na szczycie bieżącego zatwierdzenia. Gdy stan jest nieprawidłowy, należy powrócić do wiersza polecenia, ponieważ obecnie nie ma obsługi resetowania w środowisku IDE.

Autorzy: Jesse Houwing, Martin Hinshelwood, Mike Fourie i Willy Schaub z ALM | DevOps Rangers. Połącz się z nimi tutaj.

c) 2015 Microsoft Corporation. Wszelkie prawa zastrzeżone. Ten dokument jest dostarczany "w stanie, w jakim się znajduje". Informacje i opinie wyrażone w tym dokumencie, w tym adres URL i inne odwołania do witryn internetowych, mogą ulec zmianie bez powiadomienia. Ryzyko korzystania z niniejszego dokumentu ponosi użytkownik.

Na mocy niniejszego dokumentu użytkownik nie uzyskuje jakichkolwiek praw do własności intelektualnej zawartej w jakimkolwiek produkcie firmy Microsoft. Dozwolone jest kopiowanie niniejszego dokumentu i korzystanie z niego do własnych celów pomocniczych.