Omówienie sposobu mapowania poleceń funkcji Kontrola wersji serwera Team Foundation (TFVC) na przepływy pracy usługi Git
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Czy planujesz wdrożyć usługę Git, zapoznasz się z akcjami kontroli wersji serwera Team Foundation i zastanawiasz się, jak są mapowane na usługę Git? Oba są zaawansowanymi i dojrzałymi systemami kontroli źródła. Jednak mapowanie typowych akcji, do których przyzwyczailiśmy się w tym drugim, może być mylące środowisko.
Ten artykuł nie zagłębia się w polecenia git, ponieważ są one dobrze udokumentowane w dokumentacji produktu, ale pokazują przykłady ułatwiające podejmowanie odpowiednich decyzji podczas przechodzenia przez typowe tworzenie —> klonowanie —> gałąź —> zmienianie — zatwierdzanie —>> wypychanie przepływu pracy.
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.
Po utworzeniu repozytorium zostaną wyświetlone instrukcje krok po kroku, aby szybko rozpocząć pracę.
Kliknij pozycję Utwórz plik ReadMe na końcu strony instrukcji, aby nadać kontekst repozytorium i utworzyć historię.
Tworzenie obszaru roboczego i uzyskiwanie najnowszej wersji
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 clone Git do folderu na maszynie. Klonowanie spowoduje pobranie całej zawartości i historii repozytorium na komputer lokalny. Po sklonowanym 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ć raz na repozytorium, ale podobnie jak w przypadku obszarów roboczych TFVC, możesz mieć wiele klonów, aby odizolować pracę w toku. Jednak rozgałęzianie jest zazwyczaj lepszym sposobem odizolowania zmian.
Tworzenie gałęzi
W usłudze Git zawsze pracujesz w gałęzi i domyślnie wmain 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 gałęziami i pracą w izolacji. W przeciwieństwie do gałęzi TFVC, które są ograniczone do ścieżek, gałęzie usługi Git mają zakres repozytorium. Są lekkie, mogą być tylko lokalne lub udostępniane innym osobom, gdy wszystko będzie gotowe do udostępnienia zmian.
Rozważ rozgałęzianie, jeśli musisz pracować w izolacji, musisz zawiesić swoją pracę, skoncentrować się na nowych funkcjach lub jeśli planujesz przeprowadzić żądanie ściągnięcia usługi 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 git status jest uruchomienie najpierw, aby sprawdzić, czy jesteś w odpowiedniej gałęzi, aby rozpocząć od.
git checkout -b francis/demo-feature
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. Nowe pliki można przygotować za git add pomocą polecenia , co jest synonimem wykonywania add Items to Folder operacji 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 w środowisku roboczym? Tak jak wcześniej, polecenie Git status lub Changes widok w środowisku IDE programu Visual Studio pokaże zmiany w drzewie roboczym.
git status
Zaewidencjonuj zmiany i zatwierdź lokalnie
W programie TFVC zmiany są udostępniane Synchronizacja, która wysyła oczekujące zmiany na serwer. Proces git jest nieco 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:
fetchaby pobrać zawartość i wyświetlić podgląd zmian przychodzących od innych.pullaby pobrać, a następnie scalić zmiany z innych.pushaby udostępnić zmiany lokalne.
Wyświetl historię
Aby wyświetlić zatwierdzenie, właśnie utworzono, możesz przejrzeć historię lokalną.
W przypadku kompaktowej historii użyj:
git log --oneline
Aby uzyskać szczegółowe informacje, wyświetl, użyj:
git log
Jak pokazano powyżej, git log wyświetla listę autorów, wiadomości e-mail, daty zapisu i sumy kontrolnej SHA-1 zatwierdzenia. Jako użytkownik tfVC możesz użyć --stat opcji , 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 pozycję Historia kodu > lub Historia Eksploratora > kodu >
W tym momencie pomyślnie zbadano tworzenie —> klonowanie — gałąź —>> zmienianie —> zatwierdzanie —> wypychanie przepływu pracy na podstawie typowych akcji kontroli wersji serwera TEAMVC.
Istnieje również możliwość wystawienia żądania ściągnięcia w celu opublikowania i przygotowania zmian 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 checkoutpolecenie , dzięki czemu cały katalog roboczy jest zgodny z wybraną gałęzią lub zatwierdzeniem. 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 synonimem 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 kontroli wersji serwera Team Foundation.
Alternatywnie możesz ręcznie usunąć repozytorium lokalne — po utworzeniu zweryfikowanej kopii oczywiście — a następnie clone ponownie 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:
- Polecenia git omówione w niniejszym dokumencie, zapoznaj się z dokumentacją usługi Git
- Pomyśl jak (a) Git, przewodnik dla zakłopotany.
- Jak cofnąć (prawie) wszystko za pomocą usługi Git, autor: Joshua Wehner
Q&A
Co z synchronizacją?
"Czy środowisko IDE Commit and Sync programu Visual Studio nie ma magicznie tego wszystkiego?", możesz zadać sobie pytanie.
Wybierz pozycję Git>Commit lub Stash , aby otworzyć zmiany usługi 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ę.
Z magią przychodzi odpowiedzialność! Wielu użytkowników nie lubi sync tego, ponieważ czasami może nie zadzierać historii lokalnej i dodać zatwierdzenie scalania na podstawie 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 "zgodnie z rzeczywistymi elementami". Informacje i widoki 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.