Zarządzanie rozgałęzianiami i żądaniami ściągnięcia

Ukończone

Wskazówka

Aby uzyskać więcej szczegółów, zobacz kartę Tekst i obrazy .

Programowanie współpracy w usłudze Azure Databricks opiera się na skutecznych rozwiązaniach dotyczących kontroli wersji. Gdy wielu członków zespołu pracuje jednocześnie nad notesami i plikami kodu, potrzebujesz ustrukturyzowanego podejścia do izolowania zmian, przeglądania kodu i integrowania pracy bez zakłócania pracy produkcyjnych.

Diagram przedstawiający sposób zarządzania rozgałęzianiami, żądaniami ściągnięcia i konfliktami.

Foldery Git w Azure Databricks udostępniają wizualnego klienta Git, który integruje się bezpośrednio z obszarem roboczym. Ta integracja umożliwia wykonywanie typowych operacji usługi Git — rozgałęzianie, zatwierdzanie i scalanie — bez opuszczania środowiska usługi Azure Databricks.

Tworzenie gałęzi i zarządzanie nimi

Gałęzie funkcjonalne izolują twoją pracę od głównej bazy kodu. Podczas tworzenia gałęzi w usłudze Azure Databricks można opracowywać i testować zmiany niezależnie przed scaleniem ich z udostępnionymi gałęziami.

Aby utworzyć nową gałąź:

  1. Otwórz okno dialogowe Git, wybierając przycisk branży obok nazwy notatnika.
  2. Wybierz pozycję Utwórz gałąź i wprowadź opisową nazwę.
  3. Oprzyj swoją gałąź na podstawie odpowiedniej gałęzi źródłowej, zazwyczaj main.

Zrzut ekranu przedstawiający okno dialogowe tworzenia gałęzi Git.

Użyj spójnej konwencji nazewnictwa dla gałęzi, aby wyraźnie zidentyfikować pracę. Typowe wzorce obejmują:

  • feature/feature-name dla nowych funkcji
  • bugfix/issue-description na poprawki
  • users/username/description do pracy w zakresie rozwoju osobistego

Po przełączeniu gałęzi niezatwierdzone zmiany są przenoszone do nowej gałęzi, jeśli nie powodują konfliktu z istniejącym kodem. Odrzuć zmiany przed przełączeniem, jeśli nie zamierzasz przenosić ich do nowej gałęzi.

Ważne

Przełączanie gałęzi może usuwać zasoby obszaru roboczego, gdy nowa gałąź nie zawiera tych zasobów. Przed przełączeniem sprawdź, czy zasób istnieje w gałęzi docelowej, zwłaszcza jeśli notesy zostały udostępnione lub z zakładkami.

Zatwierdzanie i wypychanie zmian

Po zmodyfikowaniu notesów lub plików zatwierdź zmiany, aby utworzyć migawkę w historii swojej gałęzi. Interfejs użytkownika folderów Git wyróżnia zmodyfikowane pliki i pokazuje różnice wizualne , dzięki czemu można przeglądać zmiany przed zatwierdzeniem.

Aby zatwierdzić i przesłać zmiany:

  1. Otwórz okno dialogowe Git z notesu lub przeglądarki obszaru roboczego.
  2. Przejrzyj listę zmienionych plików w oknie dialogowym.
  3. Wprowadź opisowy komunikat zatwierdzenia, który wyjaśnia, co się zmieniło i dlaczego.
  4. Wybierz pozycję Zatwierdź i wypchnij , aby zapisać zmiany i zsynchronizować je z repozytorium zdalnym.

Jeśli nie masz uprawnień do zatwierdzania zmian bezpośrednio w chronionych gałęziach, takich jak main, utwórz najpierw gałąź funkcjonalną. Następnie możesz użyć interfejsu dostawcy usługi Git, aby utworzyć żądanie ściągnięcia do scalenia.

Uwaga / Notatka

Rezultaty z notesu nie są domyślnie uwzględniane w zatwierdzeniach, gdy notesy używają formatów plików źródłowych, takich jak .py, .scala, .sql lub .r. Jeśli chcesz kontrolować wersje danych wyjściowych, użyj formatu IPYNB.

Praca z pull requestami

Żądania pull umożliwiają członkom zespołu przeglądanie zmian kodu przed scaleniem ich w udostępnione gałęzie. Azure Databricks udostępnia operacje git na potrzeby rozgałęziania i zatwierdzania, a tworzysz i przeglądasz pull requesty za pośrednictwem interfejsu swojego dostawcy usługi Git — GitHub, Azure DevOps, GitLab lub Bitbucket.

Typowy workflow współpracy obejmuje następujące kroki:

  1. Sklonuj repozytorium do obszaru roboczego usługi Azure Databricks.
  2. Utwórz gałąź funkcjonalną z main.
  3. Wprowadź modyfikacje notesów i plików.
  4. Zatwierdź i wypchnij zmiany do zdalnego repozytorium.
  5. Otwórz witrynę internetową dostawcy usługi Git i utwórz żądanie ściągnięcia.
  6. Przejrzyj kod z zespołem i prześlij opinię.
  7. ** Połącz pull request do gałęzi wdrożeniowej.

Databricks zaleca, aby każdy deweloper pracował nad swoją własną gałęzią, aby zminimalizować konflikty. Gdy współtwórcy wypychają do tego samego folderu Git, przełączenie gałęzi przez jednego użytkownika wpływa na wszystkich współużytkujących ten folder.

Po scaleniu pull requesta można zsynchronizować zmiany z lokalnym obszarem roboczym, pobierając zaktualizowaną gałąź.

Rozwiązać konflikty scalania

Konflikty scalania występują, gdy wielu użytkowników modyfikuje te same wiersze pliku, a usługa Git nie może automatycznie określić, które zmiany mają być zachowywane. Konflikty mogą wystąpić podczas operacji pobierania, scalania lub przenoszenia baz.

W przypadku wystąpienia konfliktu interfejs użytkownika folderów Git wyświetla listę plików powodujących konflikt z opcjami rozwiązywania problemów:

Zachowaj bieżące lub podejmuj zmiany przychodzące: użyj tego podejścia, jeśli wiesz, że wszystkie zmiany mają być przyjmowane z jednego źródła. Wybierz pozycję Zachowaj wszystkie bieżące zmiany lub Przyjmij wszystkie zmiany przychodzące.

Ręczne rozwiązywanie: w przypadku złożonych konfliktów edytuj plik bezpośrednio. Git oznacza sekcje powodujące konflikt znacznikami.

<<<<<<< HEAD
Your current changes
=======
Incoming changes
>>>>>>> branch-name

Usuń znaczniki i edytuj zawartość, aby zachować prawidłowy kod. Po zakończeniu wybierz pozycję Oznacz jako rozwiązane .

Po rozwiązaniu wszystkich konfliktów wybierz pozycję Kontynuuj scalanie lub Kontynuuj ponowną bazę, aby ukończyć operację. Jeśli dokonano nieprawidłowych wyborów, wybierz pozycję Przerwij , aby anulować i powrócić do poprzedniego stanu.

Wskazówka

Często pobieraj zmiany z repozytorium zdalnego, aby wcześnie wykrywać konflikty. Małe, częste scalania są łatwiejsze do rozwiązania niż duże, złożone.

Dzięki tym umiejętnościom rozgałęziania i rozwiązywania konfliktów możesz skutecznie uczestniczyć w przepływach pracy tworzenia zespołu. Następnym krokiem jest zrozumienie sposobu integracji tych rozwiązań z szerszymi procesami ciągłej integracji/ciągłego wdrażania na potrzeby wdrażania kodu w środowiskach.