Erstellen und Verwalten von Git-Ordnern

Auf dieser Seite wird beschrieben, wie Sie Git-Ordner für Azure Databricks erstellen und allgemeine Git-Vorgänge ausführen, einschließlich Klonen, Verzweigung, Commit und Pushing.

In diesem Handbuch werden die folgenden Git-Vorgänge behandelt:

Klonen eines Repositorys

Wenn Sie ein Remote-Repository klonen, erstellt Databricks einen Git-Ordner in Ihrem Arbeitsbereich, der den Repositoryinhalt enthält, und verfolgt Änderungen. Sie können Git-Ordner mithilfe der Azure Databricks-Benutzeroberfläche oder des Webterminals erstellen.

Aus der Benutzeroberfläche klonen

1. Wählen Sie in der Randleiste "Arbeitsbereich" aus, und navigieren Sie zu dem Ordner, in dem Sie den Git-Repository-Klon erstellen möchten.

2. Klicken Sie auf"Git-Ordner erstellen>".

3. Geben Sie im Dialogfeld Git-Ordner erstellen die folgenden Informationen an:

   Feld	Description
   Git-Repository-URL	Die URL des Git-Repositorys, das Sie klonen möchten, im Format https://example.com/organization/project.git.
   Git-Anbieter	Git-Anbieter für das Repository, das Sie klonen möchten.
   Git-Ordnername	Der Name des Ordners in Ihrem Arbeitsbereich, der den Inhalt des geklonten Repositorys enthält.
   Sparse-Checkout-Modus	Soll sparse checkout verwendet werden, wodurch nur eine Teilmenge der Verzeichnisse Ihres Repositorys mithilfe eines Kegelmusters geklont wird? Dies ist nützlich, wenn Ihr Repository die Größenbeschränkungen überschreitet.

4. Klicken Sie auf Git-Ordner erstellen. Der Inhalt des Remote-Repositorys wird in Ihren Arbeitsbereich geklont, und Sie können mit unterstützten Git-Vorgängen arbeiten. Wenn Ihr Arbeitsbereich berechtigt ist, wird der Git-Ordner automatisch mit Git CLI-Zugriff erstellt. Siehe Wann erhält ein Git-Ordner Git CLI-Zugriff?.

Webterminal klonen

Sie können auch Git-Ordner mit CLI-Zugriff direkt über das Webterminal erstellen:

1. Greifen Sie auf das Webterminal zu. Siehe Ausführen von Shellbefehlen im Azure Databricks-Webterminal.

2. Navigieren Sie zum übergeordneten Verzeichnis in /Workspace:

   cd /Workspace/Users/<your-email>/<project>
   

3. Klonen Sie Ihr Repository:

   git clone <remote-url>
   

   Der git clone Befehl verwendet die in Ihrem Arbeitsbereich konfigurierten Git-Anmeldeinformationen. Siehe Verbinden Ihres Git-Anbieters mit Databricks.

4. Aktualisieren Sie Ihren Browser, um den neuen Ordner im Arbeitsbereichsdateibrowser anzuzeigen.

Verwenden von Git CLI-Befehlen

Git-Ordner mit Git CLI-Zugriff ermöglichen Ihnen das Ausführen standardmäßiger Git-Befehle auf serverlosem Compute, aus einem Notizbuch, dem Webterminal oder Genie Code. Sie haben folgende Möglichkeiten:

• Führen Sie einen beliebigen Git-Befehl aus, einschließlich git stash, git push --forceund git rebase -i.
• Integrieren Sie Linting und Codescans in Pre-Commit-Hooks.
• Arbeiten Sie mit Repositorys, die die Grenzwerte von 2 GB Arbeitsspeicher und 4 GB Datenträgern von Standard-Git-Ordnern überschreiten.
• Verwenden Sie Git-Untermodule und großen Dateispeicher (Large File Storage, LFS).
• Führen Sie lokal mehrere Commits aus, bevor Sie sie an das Remote-Repository übertragen.

Git CLI-Computeanforderungen

Die erforderliche Berechnung hängt davon ab, wie Sie einen CLI-aktivierten Git-Ordner verwenden:

Informationen zum Aktivieren der serverlosen Berechnung finden Sie unter Herstellen einer Verbindung mit serverlosem Compute.

Wenn Ihr Git-Anbieter private Netzwerkkonnektivität erfordert, lesen Sie " Konfigurieren der Netzwerkkonnektivität".

Wann erhält ein Git-Ordner Git CLI-Zugriff?

Wenn Sie einen Git-Ordner über die Benutzeroberfläche erstellen, aktiviert Azure Databricks den Git CLI-Zugriff automatisch, wenn Ihr Arbeitsbereich berechtigt ist. Wenn Ihr Arbeitsbereich nicht berechtigt ist, erstellt Azure Databricks stattdessen einen standardmäßigen Git-Ordner, und Sie können weiterhin Git-Vorgänge über die Benutzeroberfläche der Git-Ordner ausführen.

Ein Git-Ordner, den Sie über die Benutzeroberfläche erstellen, erhält Git CLI-Zugriff, wenn alle folgenden Bedingungen zutreffen:

• Die Git CLI-Vorschau ist für Ihren Arbeitsbereich aktiviert. Arbeitsbereichsadministratoren steuern dies über die Vorschauseite . Siehe Verwalten von Azure Databricks-Vorschauen.
• Serverlose Berechnung steht in Ihrem Arbeitsbereich zur Verfügung. Siehe Verbindung mit serverlosem Computing herstellen.
• Azure Databricks kann Ihren Git-Provider aus serverlosem Computing heraus erreichen. Azure Databricks überprüft die Konnektivität, bevor das Repository geklont wird. Wenn Ihr Git-Anbieter private Netzwerkkonnektivität erfordert, lesen Sie " Konfigurieren der Netzwerkkonnektivität".
• Während der öffentlichen Vorschau sind Repositorys auf 10.000 Dateien beschränkt. Repositories, die diesen Grenzwert überschreiten, werden stattdessen als normale Git-Ordner geklont.

Git-Ordner, die Sie vom Webterminal klonen, verfügen immer über Git CLI-Zugriff.

Erstellen eines Git-Ordners mit Git CLI-Zugriff

So erstellen Sie einen Git-Ordner mit CLI-Zugriff:

• Wenn Sie die Benutzeroberfläche verwenden, erstellt Azure Databricks den Git-Ordner mit Git CLI-Zugriff automatisch, wenn Ihr Arbeitsbereich berechtigt ist. Siehe Wann erhält ein Git-Ordner Git CLI-Zugriff?. Wenn Ihr Arbeitsbereich nicht berechtigt ist, erstellt Azure Databricks stattdessen einen Standardmäßigen Git-Ordner.
• Wenn Sie das Webterminal verwenden, verfügt jedes Repository, das Sie klonen, automatisch über Git CLI-Zugriff.

Nachdem Sie einen Git-Ordner mit CLI-Zugriff erstellt haben, führen Sie einen beliebigen Standard-Git-Befehl über das Webterminal aus. Informationen zum Öffnen eines Webterminals finden Sie unter "Starten des Webterminals".

cd /Workspace/Users/<your-email>/<project>/my-repo

# Interactive rebase
git rebase -i main

# Stash uncommitted changes
git stash

# Work with submodules
git submodule update --init --recursive

Einschränkungen der Git CLI

Git-Ordner mit CLI-Zugriff haben die folgenden Einschränkungen:

• Git-URL-Zulassungslisten gelten für Git-Vorgänge, die Sie über die Azure Databricks UI ausführen, jedoch nicht für Git-Befehle erzwungen werden, die Sie direkt mit der Git CLI ausführen.
• Git-Ordner mit Git CLI-Zugriff werden nicht von der Liste Repos-API zurückgegeben.

Fehlerbehebung von Git CLI-Vorgängen

• Git-Vorgänge sind in der Arbeitsbereichsbenutzeroberfläche deaktiviert: Serverlose Berechnung ist in Ihrem Arbeitsbereich nicht aktiviert. Sie können weiterhin Git-Befehle über das Webterminal ausführen. Informationen zum Aktivieren der serverlosen Berechnung finden Sie unter Herstellen einer Verbindung mit serverlosem Compute.
• Terminal fordert Sie auf, eine Anmeldeinformation auszuwählen: Git CLI-Vorgänge verwenden automatisch Ihre gespeicherten Arbeitsbereich-Git-Anmeldeinformationen . Azure Databricks leitet den Git-Anbieter von der Remote-URL ab und verwendet die Standardanmeldeinformationen für diesen Anbieter. Wenn Azure Databricks keine einzelnen zu verwendenden Anmeldeinformationen identifizieren können, werden Sie aufgefordert, eines auszuwählen. Um die Eingabeaufforderung zu vermeiden, legen Sie die DB_GIT_CREDENTIAL_NAME Umgebungsvariable auf den Namen der Anmeldeinformationen fest, die Sie verwenden möchten. Azure Databricks merkt sich die Anmeldeinformationen, die Sie für ein Repository verwenden, und verwendet sie wieder.
• Git-Vorgänge schlagen mit Berechtigungsfehlern fehl: Vergewissern Sie sich, dass Sie über die Berechtigung für den übergeordneten Ordner verfügen CAN MANAGE und dass Ihre Arbeitsbereich-Git-Anmeldeinformationen gültig sind. Siehe Verbinden Ihres Git-Anbieters mit Databricks.

Zugreifen auf das Dialogfeld „Git“

Greifen Sie über ein Notizbuch oder über den Git-Ordnerbrowser von Azure Databricks auf das Git-Dialogfeld zu.

• Klicken Sie in einem Notizbuch auf die Schaltfläche neben dem Notizbuchnamen, der die aktuelle Git-Verzweigung identifiziert.

  

• Klicken Sie im Azure Databricks Git-Ordnerbrowser neben dem Repositorynamen auf Git .

Ein Dialogfeld im Vollbildmodus wird angezeigt, in dem Sie Git-Vorgänge ausführen können.

1. Ihre aktuelle Arbeitsverzweigung. Sie können hier weitere Branches auswählen. Wenn andere Benutzende Zugriff auf diesen Git-Ordner haben, ändert das Wechseln der Verzweigung auch die Verzweigung für sie, wenn sie denselben Arbeitsbereich freigeben. Hier können Sie sich eine bewährte Methode ansehen, um dieses Problem zu vermeiden.
2. Erstellen eines neuen Branches.
3. Dateien und Unterordner, die in Ihre aktuelle Verzweigung eingecheckt sind.
4. Zeigt den aktuellen Verzweigungsverlauf an.
5. Abrufen von Inhalten aus dem Remote-Git-Repository.
6. Fügen Sie eine Commit-Nachricht und eine optionale erweiterte Beschreibung für Ihre Änderungen hinzu.
7. Übernehmen Sie Ihre Arbeit auf die Arbeitsverzweigung und pushen Sie die aktualisierte Verzweigung zum Remote-Git-Repository.

Klicken Sie auf das , um aus zusätzlichen Git-Verzweigungsvorgängen auszuwählen, z. B. einem „Hard Reset“, „Merge“ oder „Rebase“.

Einen neuen Zweig erstellen

So erstellen Sie eine neue Verzweigung:

1. Öffnen Sie das Git-Dialogfeld.
2. Klicke auf Branch erstellen.
3. Geben Sie einen Namen für die neue Verzweigung ein, und wählen Sie den Basiszweig aus.
4. Klicken Sie auf "Erstellen".

Wechseln zu einem anderen Branch

Um eine andere Verzweigung auszuchecken, verwenden Sie das Branch-Dropdown im Git-Dialogfeld.

Nicht abgeschlossene Änderungen an der aktuellen Verzweigung werden übernommen und als nicht abgeschlossene Änderungen an der neuen Verzweigung angezeigt, wenn die nicht übernommenen Änderungen keinen Konflikt mit Code in der neuen Verzweigung verursachen. Verwerfen Sie die Änderungen vor oder nach Verzweigungswechseln, wenn Sie die Änderungen ohne Commit nicht übernehmen möchten.

Die lokale Version einer Verzweigung kann bis zu 30 Tage nach dem Löschen der Remote-Verzweigung im zugeordneten Git-Ordner vorhanden bleiben. Um eine lokale Verzweigung in einem Git-Ordner vollständig zu entfernen, löschen Sie das Repository.

Änderungen committen und pushen

Wenn Sie neue Notizbücher oder Dateien hinzufügen oder Änderungen an vorhandenen Notizbüchern oder Dateien vornehmen, hebt die Benutzeroberfläche des Git-Ordners die Änderungen hervor.

Fügen Sie eine erforderliche Commit-Nachricht für die Änderungen hinzu, und klicken Sie auf Commit und Push , um die Änderungen an das Remote-Git-Repository zu übertragen.

Wenn Sie nicht über die Berechtigung zum Commit auf den Standardbranch verfügen, erstellen Sie einen neuen Branch und verwenden Sie die Schnittstelle Ihres Git-Anbieters, um eine Pull-Anfrage zu erstellen und sie in den Standardbranch zu mergen.

Autor in einem Git-Ordner, während er in einer Rolle agiert

Mit RBACnehmen Sie eine Rolle an, um auf Daten zuzugreifen, die auf diese Rolle beschränkt sind. Um Code zu erstellen, der diese Daten liest, nehmen Sie die Rolle an, damit der Datenzugriff wirksam ist, und übernehmen Sie dann die Änderungen. Sie können den Commit entweder mit Ihrer eigenen Benutzeridentität oder mit der Rolle ausführen. Die Wahl bestimmt, wie Ihr Git-Anbieter Commits zuordnet, im Verhältnis dazu, wie viel Einrichtungsaufwand der Workflow erfordert. Beide hängen von den Git-Anmeldeinformationen der Rolle ab.

Übernehmen unter Ihrer Benutzeridentität

Bei diesem Ansatz führen Sie mit Ihren persönlichen Git-Zugangsdaten einen Commit durch, sodass Ihr Git-Anbieter die Commits Ihnen zuordnet. Sie übernehmen die Rolle nur, um Änderungen an den Daten vorzunehmen, auf die die Rolle zugreifen kann, und wechseln dann zu Ihrer Benutzeridentität zurück, um einen Commit durchzuführen. Da Sie Änderungen als Rolle verfassen, aber den Commit mit Ihrer Benutzeridentität durchführen, muss der Git-Ordner unter beiden Identitäten erreichbar sein. Richten Sie dies auf eine von zwei Arten ein, die sich darin unterscheiden, wem der Ordner gehört und in welche Richtung Sie ihn freigeben.

Option 1: Klonen Sie es in Ihr Home-Verzeichnis und teilen Sie es mit der Rolle.

1. Klonen Sie das Repository mit Ihrer Benutzerkennung (übernehmen Sie diese Rolle nicht) in einen Git-Ordner in Ihrem Home-Verzeichnis (/Workspace/Users/<your-username>/...). Siehe Klonen eines Repositorys. Der Klon verwendet Ihre persönlichen Git-Anmeldeinformationen, und Sie besitzen den Ordner. Die Rolle benötigt keine eigenen Git-Anmeldeinformationen für diese Option.
2. Gewähren Sie der Rolle Zugriff auf den Ordner (Kann ausführen oder kann bearbeiten , wenn die Rolle Dateien ändern muss), damit Sie daran arbeiten können, während Sie als Rolle fungieren.
3. Nehmen Sie die Rolle an, und nehmen Sie dann Ihre Änderungen im Ordner vor. Der Datenzugriff der Rolle ist aktiv.
4. Wechseln Sie zurück zu Ihrer Benutzeridentität, und führen Sie einen Commit durch, und übertragen Sie ihn. Der Commit verwendet Ihre persönlichen git_username und git_email.

Da Sie den Ordner aus Ihrer Benutzeridentität für die Rolle freigeben, wirken sich die Steuerelemente für die Freigabe von Arbeitsbereichsobjekten nicht auf diese Option aus. Diese Steuerelemente schränken nur eine Rolle bei der Freigabe von Ressourcen nach außen ein.

Option 2: Im Home-Ordner der Rolle klonen und mit Ihrer Benutzeridentität teilen

1. Übernehmen Sie die Rolle , und klonen Sie das Repository in einem Git-Ordner im Startordner der Rolle. Beim Klonen werden die Git-Anmeldedaten der Rolle verwendet, die mindestens über Lesezugriff verfügen müssen.
2. Während Sie als Rolle fungieren, gewähren Sie Ihrer Benutzeridentität Zugriff auf den Ordner (Kann bearbeiten).
3. Nehmen Sie Ihre Änderungen vor, während Sie in der Rolle agieren. Der Datenzugriff der Rolle ist aktiv.
4. Wechseln Sie zurück zu Ihrer Benutzeridentität. Da Sie Ihrem Benutzerkonto Zugriff gewährt haben, können Sie auf den Ordner zugreifen. Führen Sie also einen Commit aus und pushen Sie mit Ihren persönlichen Zugangsdaten. Der Commit verwendet Ihre persönlichen git_username und git_email.

Da die Rolle den Ordner extern für Ihre Benutzeridentität freigibt, funktioniert diese Option nicht, wenn die Rolle auf der Sperrliste der Freigabesteuerung für Workspace-Assets steht. Verwenden Sie Option 1 für diese Rollen.

Als die Rolle committen

Bei diesem Ansatz klonen Sie, erstellen und übernehmen sie alle, während Sie in der Rolle fungieren. Dies ist der einfachste Workflow: Du gibst keinen Ordner frei und musst nicht die Identität wechseln, um zu committen. Es erfordert die Git-Anmeldeinformationen der Rolle, um Schreibzugriff zu haben, da die Arbeitsbereich-UI commits und Pushs in einer einzigen Aktion übernimmt.

1. Übernehmen Sie die Rolle.
2. Klonen Sie das Repository in einen Git-Ordner. Da Sie in der Rolle handeln, verwendet der Klonvorgang die Git-Anmeldedaten der Rolle.
3. Nehmen Sie Ihre Änderungen vor, und führen Sie einen Commit durch, und übertragen Sie sie. Der Commit verwendet git_username und git_email der Rolle.

Wiegen Sie diese Auswirkungen, bevor Sie diesen Ansatz auswählen:

• Die Zuordnung erfolgt auf Rollenebene. Commits in Ihrem Git-Anbieter zeigen die Git-Identität der jeweiligen Rolle und nicht die der einzelnen Autorin bzw. des einzelnen Autors an. Azure Databricks-Überwachungsprotokolle zeichnen bei Commits, die über die Benutzeroberfläche des Arbeitsbereichs vorgenommen werden, sowohl identity_metadata.run_as (die Rolle) als auch identity_metadata.run_by (Sie) auf. Dies gilt nicht für unformatierte Git-Commits, die von der Git CLI in einem Webterminal ausgeführt werden, das Azure Databricks keinem einzelnen Benutzer attributiert.
• Die Git-Anmeldeinformationen der Rolle sind freigegeben und mit Schreibzugriff versehen. Jeder, der diese Rolle annimmt, verwendet dieselben Anmeldedaten zum Pushen, sodass mit einem offengelegten oder missbräuchlich verwendeten Token unter der Identität der Rolle gepusht, Verzweigungen gelöscht oder Commits verfasst werden können. Aus diesem Grund empfiehlt Azure Databricks gruppenbezogene Git-Anmeldeinformationen mit Lesezugriff und den Ansatz Commit mit Ihrer Benutzeridentität. Verwenden Sie schreibfähige Anmeldeinformationen nur, wenn Sie diese Kompromisse akzeptieren. Siehe Tokenberechtigungen. Beschränken Sie die Anmeldedaten auf genau die Repositorys, die für die Rolle erforderlich sind.

Änderungen abrufen

Zum Pullen von Änderungen aus dem Git-Remoterepository klicken Sie im Dialogfeld für Git-Vorgänge auf Pullen. Notizbücher und andere Dateien werden automatisch auf die neueste Version in Ihrem Remote-Git-Repository aktualisiert. Wenn die änderungen, die aus dem Remote-Repository abgerufen wurden, mit Ihren lokalen Änderungen in Azure Databricks in Konflikt geraten, lösen Sie die Zusammenführungskonflikte.

Zusammenarbeiten in Git-Ordnern

Git-Ordner von Azure Databricks verhalten sich als eingebettete Git-Clients in Ihrem Arbeitsbereich, sodass Sie über gitbasierte Quellcodeverwaltung und Versionsverwaltung zusammenarbeiten können. Für eine effektive Teamzusammenarbeit:

• Jedes Teammitglied verfügt über einen eigenen Git-Ordner, der dem Remote-Git-Repository zugeordnet ist, in dem er in einem eigenen Entwicklungszweig arbeitet.
• Nur ein Benutzer führt Git-Vorgänge für jeden Git-Ordner aus. Mehrere Benutzer, die Git-Vorgänge im selben Ordner ausführen, können Zu Problemen bei der Verzweigungsverwaltung führen, z. B. unbeabsichtigtes Wechseln von Verzweigungen für jeden Benutzer.

So geben Sie Ihre Git-Ordnerkonfiguration für einen Mitarbeiter frei:

1. Klicken Sie auf Freigeben.
2. Klicken Sie auf "Link kopieren", um den Git-Ordner zu erstellen.
3. Senden Sie die URL an Ihre Mitarbeiter.
4. Wenn Ihre Mitarbeiter die URL öffnen, wird ein Dialogfeld angezeigt, das bereits mit Ihrer Git-Ordnerkonfiguration ausgefüllt wurde.
5. Sie klicken auf "Git-Ordner erstellen", um das Repository in ihren eigenen Arbeitsbereich unter ihrem aktuellen Arbeitsordner zu klonen.

Verzweigungen zusammenführen

Die Zusammenführungsfunktion in Azure Databricks Git-Ordnern verwendet git merge, um den Commit-Verlauf von einer Verzweigung in eine andere zu integrieren. Bei Git-Anfängern empfiehlt Databricks die Verwendung von Merge anstelle von Rebase, da kein erzwungenes Pushen erforderlich ist und der Commitverlauf nicht neu geschrieben wird.

Um eine Verzweigung in eine andere zusammenzuführen, klicken Sie auf das und wählen Sie Zusammenführen aus.

• Wenn ein Zusammenführungskonflikt vorliegt, lösen Sie ihn in der Benutzeroberfläche der Git-Ordner.
• Wenn kein Konflikt vorliegt, wird der Merge mithilfe git push an das Remote-Git-Repository gepusht.

Auflösen von Mergekonflikten

Zusammenführungskonflikte treten auf, wenn Git Änderungen an denselben Zeilen einer Datei aus verschiedenen Quellen nicht automatisch abgleichen kann, z. B. während eines Pull-, Rebase- oder Zusammenführungsvorgangs.

Um einen Zusammenführungskonflikt zu beheben, verwenden Sie die Git-Ordner-Benutzeroberfläche, auf der konfliktierende Dateien und Lösungsoptionen angezeigt werden.

• Bearbeiten Sie die Datei manuell, um auszuwählen, welche Änderungen beibehalten werden sollen.
• Wählen Sie "Alle aktuellen Änderungen beibehalten " aus, oder übernehmen Sie alle eingehenden Änderungen , um eine Version vollständig zu akzeptieren.
• Beenden Sie den Vorgang, und verwerfen Sie widersprüchliche Änderungen, um es erneut zu versuchen.

Manuelles Beheben von Konflikten

Mit der manuellen Konfliktlösung können Sie bestimmen, welche konfliktierenden Zeilen akzeptiert werden sollen. Bearbeiten Sie den Dateiinhalt direkt, um die Konflikte zu lösen.

Um den Konflikt zu beheben, wählen Sie die Codezeilen aus, die Sie beibehalten möchten, und löschen Sie alles andere, einschließlich der Git-Mergekonfliktmarkierungen. Wenn Sie fertig sind, wählen Sie "Als aufgelöst markieren" aus.

Wenn Sie beim Auflösen von Zusammenführungskonflikten die falschen Entscheidungen getroffen haben, klicken Sie auf "Abbrechen ", um den Vorgang abzubrechen und alles rückgängig zu machen. Nachdem alle Konflikte behoben wurden, klicken Sie auf „Fortfahren mit Zusammenführung“ oder „Fortfahren mit Rebase“, um den Konflikt zu lösen und den Vorgang abzuschließen.

Einen Branch neu basieren

Die Rebase-Funktion in Azure Databricks Git-Ordnern verwendet git rebase zur Integration von Änderungen von einer Verzweigung in eine andere, indem Commits auf der Ziel-Verzweigung erneut angewendet werden, wodurch ein linearer Verlauf entsteht.

Um eine Verzweigung auf eine andere zu rebasen, klicken Sie auf das , und wählen Sie Rebase aus, dann wählen Sie die Zielverzweigung aus.

• Nach dem Rebase werden die Befehle git commit und git push --force ausgeführt, um das Remote-Repository zu aktualisieren.
• Durch Rebase wird der Verlauf der Commits umgeschrieben, was für Mitarbeiter, die im selben Repository arbeiten, Versionierungsprobleme verursachen kann.

Zurücksetzen einer Verzweigung

Führen Sie ein Git-Reset über die Git-Ordner-Benutzeroberfläche aus. Dieser Vorgang entspricht der git reset --hard Kombination mit git push --force.

„Git reset“ ersetzt den Branchinhalt und den -verlauf durch den neuesten Status eines anderen Branchs. Sie können dies verwenden, wenn Bearbeitungen mit der Upstream-Verzweigung in Konflikt geraten, und es Ihnen nichts ausmacht, diese Änderungen zu verlieren, wenn Sie auf die Upstream-Verzweigung zurücksetzen. Weitere Informationen zu git reset --hard.

Zurücksetzen auf eine Remote-Verzweigung

Mit git reset in diesem Szenario:

• Sie setzen den ausgewählten Branch (z. B feature_a) auf einen anderen Branch (z. B main) zurück.
• Außerdem setzen Sie den Upstream (Remote) Branch feature_a auf main zurück.

So setzen Sie einen Branch auf einen Remotebranch zurück:

1. Wählen Sie im Menü Branch auf der Benutzeroberfläche für Git-Ordner den Branch aus, den Sie zurücksetzen möchten.

2. Wählen Sie " Zurücksetzen " aus dem Kebab-Menü.

   

3. Wählen Sie den Branch zum Zurücksetzen aus und klicken Sie auf Git Zurücksetzen ausführen.

Konfigurieren des Modus „Sparse Checkout“

Sparse Checkout ist eine clientseitige Einstellung, mit der Sie nur mit einer Teilmenge der Ordner des entfernten Repositorys in Azure Databricks klonen und arbeiten können. Dies ist besonders hilfreich, wenn die Größe Ihres Repositorys die von Azure Databricks unterstützten Grenzwerte überschreitet.

Aktivieren Sie den Sparse-Checkout-Modus, wenn Sie ein neues Repository klonen. Sie können den Sparse-Checkout-Modus nach der Aktivierung nicht deaktivieren.

1. Aktivieren Sie im Dialogfeld " Git-Ordner erstellen" den Auscheckmodus "Sparse".

   

2. Geben Sie im Feld Cone-Muster die gewünschten Checkout-Muster für Kegel an. Trennen Sie mehrere Muster durch Zeilenumbrüche.

Funktionsweise von Cone-Mustern

Informationen dazu, wie Kegel-Muster im Modus für Sparse-Checkout funktionieren, finden Sie im folgenden Diagramm, das die Struktur des Remote-Repositories darstellt.

Wenn Sie den Auscheckmodus "Sparse" auswählen, aber kein Kegelmuster angeben, wird das Standardkegelmuster angewendet. Dazu gehören nur die Dateien im Stammverzeichnis und keine Unterverzeichnisse, was zu einer Repositorystruktur wie folgt führt:

Das Festlegen des spärlichen Auscheckkegelmusters als parent/child/grandchild rekursiv schließt alle Inhalte des grandchild Verzeichnisses ein. Die Dateien, die sich unmittelbar in den Verzeichnissen /parent, /parent/child und im Stammverzeichnis befinden, werden ebenfalls einbezogen. Sehen Sie sich die Verzeichnisstruktur im folgenden Diagramm an:

Ändern von Einstellungen von „Sparse Checkout“

Nachdem Sie ein Repository erstellt haben, bearbeiten Sie das Muster für spärliches Auschecken unter Einstellungen>Erweitert>Kegelmuster.

Beachten Sie das folgende Verhalten:

• Wenn ein Ordner aus dem Kegelmuster entfernt wird, wird er aus Azure Databricks entfernt, wenn keine nicht hinzugefügten Änderungen vorhanden sind.

• Wenn Sie einen Ordner hinzufügen, indem Sie das dünne Auscheckkegelmuster bearbeiten, wird er zu Azure Databricks hinzugefügt, ohne dass ein zusätzlicher Pull erforderlich ist.

• Sparse-Checkout-Muster können nicht geändert werden, um einen Ordner zu entfernen, wenn nicht festgeschriebene Änderungen in diesem Ordner vorhanden sind.

  Wenn Sie z. B. eine Datei in einem Ordner bearbeiten und keine Änderungen übernehmen, versuchen Sie, das sparse Checkout-Muster so zu ändern, dass dieser Ordner ausgeschlossen wird, wird das Muster akzeptiert, aber der Ordner wird nicht gelöscht. Sie müssen das Muster wiederherstellen, um diesen Ordner einzuschließen, Ihre Änderungen zu übernehmen und dann das neue Muster erneut anwenden.

Änderungen mit Sparse-Checkout vornehmen

Bearbeiten Sie vorhandene Dateien und führen Sie Commit- und Push-Vorgänge im Git-Ordner aus. Wenn Sie neue Ordner mit Dateien erstellen, schließen Sie sie in das Cone-Muster ein, das Sie für dieses Repository angegeben haben.

Das Einbeziehen eines neuen Ordners außerhalb des Cone-Musters führt während des Commit- und Pushvorgangs zu einem Fehler. Um es zu beheben, bearbeiten Sie das Kegelmuster, um den neuen Ordner einzuschließen, den Sie commiten und pushen möchten.To fix it, edit the cone pattern to include the new folder you're trying to commit and push.

Einschränkungen beim Sparse-Checkout

• Teilweises Auschecken funktioniert nicht für Azure DevOps-Repositorys, die größer als 4 GB sind.
• Sie können das Sparse-Checkout für ein Repository nicht deaktivieren, wenn es mit aktiviertem Sparse-Checkout erstellt wurde.

Programmgesteuertes Verwalten von Git-Ordnern

Informationen zum Verwalten von Git-Ordnern mithilfe der API finden Sie in der Repos-API-Referenz.

Löschen eines Git-Ordners

So entfernen Sie einen Git-Ordner aus Ihrem Arbeitsbereich:

1. Klicken Sie mit der rechten Maustaste auf den Git-Ordner, und wählen Sie "In Papierkorb verschieben" aus.
2. Klicken Sie auf Bestätigen und in Papierkorb verschieben.

Nächste Schritte

• Richten Sie die Authentifizierung ein, um Azure Databricks mit Ihrem Git-Anbieter zu verbinden. Siehe Verbinden Ihres Git-Anbieters mit Databricks.
• Erfahren Sie mehr über Größenbeschränkungen und andere Einschränkungen für Git-Ordner. Siehe Azure Databricks Git-Ordnerbeschränkungen und -referenz.
• Konfigurieren Sie Einstellungen auf Arbeitsbereichsebene für die Git-Integration. Siehe Konfigurieren der Git-Integration für Git-Ordner.