Übung: Erstellen eines Pull Requests

12 Minuten

In dieser Lerneinheit werden Sie den Prozess des Übermittelns einer Pull-Anforderung und des Mergens Ihrer Änderungen in den main-Branch üben, damit alle von Ihrer Arbeit profitieren können.

In Create a build pipeline with Azure Pipelines (Erstellen einer Buildpipeline mit Azure Pipelines) haben Sie einen Git-Branch mit dem Namen build-pipeline erstellt, in dem Sie eine grundlegende Buildpipeline für die Space Game-Website definiert haben. Erinnern Sie sich daran, dass Ihre Builddefinition in einer Datei namens azure-pipelines.yml gespeichert ist.

Obwohl Ihr Branch ein Buildartefakt generiert, ist diese Arbeit nur für den build-pipeline-Branch vorhanden. Sie müssen ihren Branch mit main-Branch zusammenführen.

Erinnern Sie sich daran, dass eine Pull-Anforderung andere Entwickler informiert, dass Code für einen Review bereitsteht, falls erforderlich, und dass Sie Ihre Änderungen mit einen anderen Branch zusammenführen möchten, wie z.B. dem main-Branch.

Schauen wir zunächst bei Mara und Andy vorbei, bevor wir beginnen.

Andy: Hallo Mara. Ich weiß, dass Du eine Buildpipeline in Azure ausführst. Ich füge der Website eine Funktion hinzu und möchte mir den Buildprozess selbst anschauen. Geht das?

Mara: Natürlich. Ich habe die Pipeline in einem Branch erstellt. Warum erstellen wir nicht eine Pull-Anforderung und führen sie mit main zusammen, damit Sie die Pipeline ebenfalls nutzen können?

Andy: Das klingt gut. Wir sehen uns dies nun genauer an.

Erstellen einer Verzweigung und Hinzufügen von Startercode

Obwohl Sie die Buildpipeline verwenden könnten, die Sie im vorherigen Modul erstellt haben, erstellen wir nun einen neuen Branch namens code-workflow. Dieser Branch basiert auf main, damit Sie den Prozess von Anfang an üben können.

Öffnen Sie in Visual Studio Code das integrierte Terminal.
Wechseln Sie in den main-Branch:
```
git checkout main
```
Stellen Sie sicher, dass Sie über die neueste Version des Codes von GitHub verfügen:
```
git pull origin main
```
Erstellen Sie einen Branch namens code-workflow:
```
git checkout -B code-workflow
```
Das -b-Argument gibt an, dass ein neuer Branch erstellt werden soll, wenn er nicht vorhanden ist. Lassen Sie das -b-Argument aus, wenn Sie zu einem vorhandenen Branch wechseln möchten.

Standardmäßig baut der neue Branch auf dem vorherigen Branch auf, aus dem Sie den Befehl git checkout ausgeführt haben. Hier ist der übergeordnete Branch main, aber der übergeordnete Branch kann auch ein anderer Branch sein, z. B. ein Featurebranch, der von einem anderen Benutzer gestartet wurde, auf dem Sie aufbauen oder mit dem Sie experimentieren möchten.

Jetzt können Sie alle Änderungen vornehmen, die Sie benötigen, denn Sie arbeiten in Ihrem eigenen lokalen Branch. Wenn Sie sehen möchten, in welchem Branch Sie sich befinden, führen Sie git branch -v aus.

Öffnen Sie azure.pipelines.yml im Datei-Explorer, und ersetzen Sie den Inhalt durch diesen Code:

trigger:
- '*'

pool:
  vmImage: 'ubuntu-20.04'
  demands:
  - npm

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Diese Konfiguration ähnelt der Basiskonfiguration, die Sie im vorherigen Modul erstellt haben. Der Kürze halber wird nur die Releasekonfiguration Ihres Projekts erstellt.

Pushen des Branches in GitHub

Hier pushen Sie Ihren code-workflow-Branch in GitHub und beobachten, wie Azure Pipelines die Anwendung erstellt.

Führen Sie git status im Terminal aus, um zu sehen, welcher Code in Ihrem Branch noch nicht committet wurde:
```
git status
```
Sie werden sehen, dass azure-pipelines.yml geändert wurde. Sie werden diese Datei in Kürze in Ihren Branch committen, aber Sie müssen zunächst sicherstellen, dass diese Datei von Git nachverfolgt wird, was Staging der Datei genannt wird.

Nur gestagete Änderungen werden beim Ausführen von git commit committet. Führen Sie als anschließend den Befehl git add aus, um azure-pipelines.yml dem Stagingbereich oder Index hinzuzufügen.
Führen Sie den folgenden Befehl git add aus, um azure-pipelines.yml dem Stagingbereich hinzuzufügen:
```
git add azure-pipelines.yml
```
Führen Sie den folgenden git commit-Befehl aus, um die gestagete Datei in den code-workflow-Branch zu committen:
```
git commit -m "Add the build configuration"
```
Das -m-Argument gibt die Commitnachricht an. Die Commitnachricht wird Teil der Versionsgeschichte einer geänderten Datei. Sie hilft Reviewern, die Änderungen zu verstehen und sie hilft zukünftigen Maintainern nachzuvollziehen, wie sich die Datei im Lauf der Zeit geändert hat.

Tipp

Die besten Commitnachrichten vervollständigen den Satz „Wenn Sie diesen Commit anwenden, werden Sie...“

Wenn Sie das -m-Argument auslassen, öffnet Git einen Text-Editor, in dem Sie die Änderung detailliert erläutern können. Diese Option ist nützlich, wenn Sie eine Commitnachricht angeben möchten, die mehrere Zeilen umfasst. Der Text bis zur ersten leeren Zeile gibt den Committitel an.
Führen Sie diesen git push-Befehl aus, um den code-workflow-Branch in Ihr Repository auf GitHub zu pushen oder hochzuladen:
```
git push origin code-workflow
```
Wechseln Sie als optionaler Schritt zu Ihrem Projekt in Azure Pipelines, und verfolgen Sie den Build während der Ausführung.

Dieser Build wird als CI-Build bezeichnet. Ihre Pipelinekonfiguration verwendet einen so genannten Trigger, um zu steuern, welche Branches am Buildprozess teilnehmen. Hier gibt „*“ alle Branches an.
```
trigger:
- '*'
```
Später erfahren Sie, wie Sie die Pipelinekonfiguration so steuern, dass sie nur die Branches für den Buildvorgang verwendet, die Sie benötigen.

Sie werden sehen, dass der Build erfolgreich abgeschlossen wird und ein Artefakt erstellt, das die erstellte Webanwendung enthält.

Erstellen eines Pull Request

Hier werden Sie eine Pull-Anforderung für Ihren Branch erstellen:

Melden Sie sich in einem Browser bei GitHub an.
Navigieren Sie zu Ihrem Repository mslearn-tailspin-spacegame-web.
Wählen Sie in der Dropdown Liste Branch Ihren code-workflow-Branch aus.
Zum Starten Ihres Pull Requests müssen Sie auf Contribute (Beitragen) und dann auf Open pull request (Pull Request öffnen) klicken.
Stellen Sie sicher, dass die Basis Ihr geforktes Repository und nicht das Microsoft-Repository angibt.

Ihre Auswahl sieht wie folgt aus:

Wichtig

Dieser Schritt ist wichtig, da Sie Ihre Änderungen nicht in das Microsoft-Repository mergen können. Stellen Sie sicher, dass das Basisrepository auf Ihr GitHub-Konto und nicht auf MicrosoftDocs verweist.

Wenn Sie dennoch einen Pull Request für MicrosoftDocs generiert haben, schließen Sie einfach den Pull Request und wiederholen diese Schritte.

Dieser Prozess umfasst einen zusätzlichen Schritt, da Sie aus einem geforkten Repository arbeiten. Wenn Sie direkt mit Ihrem eigenen Repository und nicht mit einer Fork arbeiten, ist Ihr main-Branch standardmäßig ausgewählt.
Geben Sie einen Titel und eine Beschreibung für Ihren Pull Request ein.
- Titel:
  
  Konfigurieren von Azure Pipelines
- Beschreibung:
  
  Diese Pipeline Konfiguration erstellt die Anwendung und generiert einen Build für die Releasekonfiguration.
Wählen Sie Create Pull Request (Pull Request erstellen) aus, um den Pull Request abzuschließen.

In diesem Schritt wird kein Code gemergt. Sie teilt anderen mit, dass Sie Änderungen vorgeschlagen haben, die in den main Branch zusammengeführt werden sollen.

Das Pull Request-Fenster wird angezeigt. Sie können sehen, dass der Buildstatus in Azure Pipelines so konfiguriert wurde, dass er als Teil des Pull Requests angezeigt wird. Auf diese Weise können Sie und andere Benutzer den Status des Builds anzeigen, während er ausgeführt wird.

Wie beim Pushen eines Branches an GitHub mithilfe löst ein Pull Request standardmäßig aus, dass Microsoft Azure Pipelines Ihre Anwendung erstellt.

Tipp

Wenn der Buildstatus nicht sofort angezeigt wird, warten Sie einen Augenblick, oder aktualisieren Sie die Seite.
Wählen Sie optional den Link Details aus, und verfolgen Sie den Build dann auf dem Weg durch die Pipeline.

Sie können den Build an den nächsten Schritt im Prozess übergeben, z. B. an QA. Später können Sie die Pipeline so konfigurieren, dass Ihre Änderungen mithilfe von Push bis zum QA-Lab oder in die Produktion übertragen werden.
Navigieren Sie zurück zu Ihrem Pull Request auf GitHub.

Warten Sie, bis der Buildvorgang abgeschlossen wird. Nun können Sie Ihren Pull Request zusammenführen.
Wählen Sie Merge Pull Request (Pull Request mergen) aus, und wählen Sie dann Confirm Merge (Mergevorgang bestätigen) aus.
Um den code-workflow-Branch aus GitHub zu löschen, wählen Sie Delete Branch (Branch löschen) aus.

Das Löschen eines Branches aus GitHub ist absolut sicher, nachdem Sie den Pull Request gemergt haben. Dies ist sogar üblich, da der Branch nicht mehr benötigt wird. Die Änderungen werden zusammengeführt. Die Details zu den Änderungen können Sie weiterhin auf GitHub oder über die Befehlszeile abrufen. Wenn Sie gemergte Branches löschen, werden anderen Entwicklern nur noch die Aufgaben angezeigt, die aktuell aktiv sind.

Git-Branches sollen kurzlebig sein. Nach dem Mergen eines Branches pushen Sie keine weiteren Commits in diesen Branch und mergen ihn auch kein zweites Mal. In den meisten Fällen beginnen Sie die Arbeit an einer neuen Funktion oder einer Fehlerkorrektur mit einem neuen Branch, der auf dem main-Branch basiert.

Durch das Löschen eines Branches auf GitHub wird dieser Branch nicht aus Ihrem lokalen System gelöscht. Dafür müssen Sie den -d-Switch an den git branch-Befehl übergeben.

Wie oft wird mit Änderungen ein Build erstellt?

Die Antwort hängt davon ab, wie Ihre Buildkonfiguration definiert ist. Mit Azure Pipelines können Sie Trigger definieren, die festlegen, durch welche Ereignisse ein Buildvorgang ausgelöst wird. Sie können steuern, für welche Branches Builds erstellt werden und sogar welche Dateien den Buildvorgang auslösen.

Nehmen wir zum Beispiel an, dass ein Build erstellt werden soll, wenn eine Änderung in GitHub oder irgendeine Git-Verzweigung gepusht wird. Der Buildvorgang soll jedoch nicht erfolgen, wenn nur Änderungen am Ordner docs Ihres Projekts vorgenommen wurden. Sie möchten möglicherweise diesen trigger-Abschnitt in Ihre Buildkonfiguration aufnehmen:

trigger:
  branches:
    include:
    - '*'     # build all branches
  paths:
    exclude:
    - docs/*  # exclude the docs folder

Standardmäßig wird ein Build ausgelöst, wenn eine Änderung in eine Datei in einem Branch gepusht wird.

Ein Continuous Integration-Build (CI-Build) wird ausgeführt, wenn Sie eine Änderung in einen Branch pushen.

Ein Pull Request-Build (PR-Build) wird ausgeführt, wenn Sie einen Pull Request öffnen oder weitere Änderungen an einen vorhandenen Pull Request pushen.

Die Änderungen, die Sie über den code-workflow-Branch vorgenommen haben, werden unter drei Bedingungen erstellt:

Es kommt zu einem CI-Build, wenn Sie Änderungen mithilfe von Push an den code-workflow-Branch übertragen.
Es kommt zu einem PR-Build, wenn Sie auf dem code-workflow-Branch einen Pull Request gegen den main-Branch öffnen.
Es kommt zu einem endgültigen CI-Build, nachdem die Pull-Anforderung mit dem main-Branch zusammengeführt wurde.

Mit PR-Builds können Sie überprüfen, ob die vorgeschlagenen Änderungen nach dem Mergen in main oder einen anderen Zielbranch tatsächlich richtig funktionieren.

Durch den endgültigen CI-Build wird überprüft, ob die Änderungen nach dem Zusammenführen des PR-Builds noch immer in Ordnung sind.

Optional können Sie zu Azure Pipelines navigieren und zusehen, wie der endgültige CI-Build für den main-Branch erstellt wird.

Übung: Erstellen eines Pull Requests

Erstellen einer Verzweigung und Hinzufügen von Startercode

Pushen des Branches in GitHub

Erstellen eines Pull Request

Wie oft wird mit Änderungen ein Build erstellt?

Feedback