Ship an API Change with GitHub Flow

Use GitHub Flow to review, merge, and revert a logistics API proposal.

Introduction

30 Second Summary

A small API change can take minutes to write. Without a clear review trail, teammates must guess what changed or why.

In this project, you will move a shipment-event proposal through GitHub Flow in your existing logistics API repository. You will create focused commits with Git before reviewing the change in a GitHub pull request.

What You'll Build

A teammate can open your merged pull request to follow the shipment-event proposal from its visual flow to its focused commit history.

By the end of this project, you'll have:

  • A rendered Markdown feature proposal that traces an API request through risk scoring to optional task creation.
  • A feature branch with two focused commits that keep the initial proposal separate from its test plan.
  • A merged pull request that preserves the visual diff for the change now present on your synchronized local default branch.
  • Secret Mission: Make a deliberately wrong commit and reverse it safely without deleting history.

Are there any prerequisites?

You need a GitHub account with write access to an existing logistics API repository. Your Windows computer needs Git plus Visual Studio Code.

Before We Start

Before the hands-on work begins, take a moment to commit to the shipment-event behavior you want reviewed. This turns the documentation change into a safe rehearsal for future API features.

Set Up a Safe Practice Clone

Your logistics API repository may already contain unfinished local work. A separate GitHub Flow rehearsal keeps that work protected.

A fresh practice clone gives Git a clean working tree.

The final checks confirm your commit identity. They also confirm the clone points to your GitHub repository.

In this step, get ready to:
  • Create a separate practice clone for the rehearsal.
  • Verify the identity Git writes into future commits.
  • Confirm a clean default branch. Verify its remote.
Clone the repository into a practice folder

A clone creates an isolated copy of your existing repository. The dedicated folder keeps this rehearsal separate from unfinished API work.

  • Press the Windows key to open Windows search.
  • Type PowerShell into the search field.
  • Press Enter to open PowerShell.

You will see a PowerShell prompt ready for commands.

  • Move to your Desktop by running this command:
cd ~/Desktop

What does this command do?

The cd command changes PowerShell's current location. The ~/Desktop path targets the Desktop inside your Windows home folder.

  • Open your existing logistics API repository page on GitHub.
  • Use the repository page's clone options to find its repository URL.
  • Copy the repository URL.
  • Replace <your-repository-url> in the command below with the copied URL.
  • Create the separate practice clone by running the edited command:
git clone <your-repository-url> logistics-api-git-lab

What does this command create?

The clone command copies the repository into a new logistics-api-git-lab folder. Git also creates the origin remote.

The clone checks out the repository's active branch. This lets the repository decide its default branch name.

  • Check the PowerShell output to confirm the clone completes without an error.

Good. The logistics-api-git-lab folder now isolates this rehearsal from your existing local API work.

Clone did not complete?

  • Confirm that you replaced <your-repository-url> with the URL copied from your repository.
  • Complete the GitHub sign-in prompt if your repository requires authentication.
  • Rename any existing logistics-api-git-lab folder before retrying the clone.

Help me diagnose why my Git repository will not clone into the practice folder.

Confirm your Git identity

Every commit records an author name plus an email address. Checking both values now prevents the practice commits from carrying a missing identity.

  • Press the Windows key to open Windows search.
  • Type Visual Studio Code into the search field.
  • Press Enter to open Visual Studio Code.

You will see the Visual Studio Code window.

  • Select File from the top menu.
  • Choose the option for opening a folder.
  • Select your Desktop in the folder picker.
  • Select the logistics-api-git-lab folder.
  • Confirm your folder selection.

The Explorer sidebar now shows the contents of logistics-api-git-lab.

  • Select Terminal from the top menu.
  • Choose the option for creating a new terminal.

The integrated terminal opens inside the logistics-api-git-lab folder.

  • Check the name plus email attached to your Git commits by running:
git config user.name
git config user.email

What do these values control?

The user.name value identifies the author shown on commits. The user.email value stores the author's commit email.

Both values should represent the identity you want attached to this repository's history.

✔️ Both identity values appear

Your Git identity is ready. The terminal shows a name plus an email address.

ⓧ One identity value is empty

An empty line means Git is missing that part of your commit identity. Set both global values before continuing.

  • Replace Your Name with the name you want attached to commits.
  • Replace you@example.com with your commit email address.
  • Configure both identity values by running the edited commands:
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

What does the global setting change?

The --global option saves your identity for repositories used by your Windows account. Future commits use these values unless a repository defines its own identity.

  • Confirm that both configured values now appear by running:
git config user.name
git config user.email

What does this check prove?

Git now resolves both identity values inside the practice clone. The two printed lines show what future commits record.

Your name plus email should now appear on separate lines.

Identity still missing?

Check that you replaced both example values before running the configuration commands. Keep the quotation marks around a name that contains spaces.

Help me configure my Git author identity in this practice clone.

Verify the remote and default branch

The final repository check ties the clone to the correct remote. It also confirms that the checked-out branch starts with no local changes.

Before you run the checks, do you expect a fresh clone to list any changed files?

  • Verify Git plus the complete practice-clone state by running:
git --version
git config user.name
git config user.email
git remote -v
git status --short --branch

What do these checks prove?

  • The version check proves the Git executable responds.
  • The user.name plus user.email values confirm the author identity.
  • The origin entries show where Git fetches plus pushes repository changes.
  • The final status shows the current branch plus any working-tree changes.

You should see a Git version followed by your configured name plus email address.

The origin addresses should point to your logistics API repository on GitHub.

The final status shows only the branch header. No file entries appear underneath it.

  • Record the branch name shown in the final status as <default-branch>.

That is the safety boundary in place. Your clean practice clone is connected to the correct repository without disturbing unfinished local work.

Remote or status looks wrong?

  • Confirm that the Explorer sidebar is rooted at logistics-api-git-lab if the status lists unexpected files.
  • Compare the origin addresses with the repository URL you copied from GitHub.
  • Rename the practice folder before cloning again if its origin points to another repository.

Help me interpret the remote plus branch status in my practice clone.

Your isolated Git environment is ready. Next, you will make the proposal visible while still on the default branch so you can feel why a review boundary matters.

Expose the Default-Branch Risk

Your fresh practice clone is clean. Its origin remote connects it to your GitHub repository.

GitHub Flow gives unfinished work a review boundary through separate branches. This step deliberately leaves a proposal on <default-branch> so the missing boundary becomes visible.

In this step, get ready to:
  • Create a shipment-event feature proposal inside the practice clone.
  • Preview the request-to-task flow as a rendered document.
  • Check which branch contains the untracked proposal.
Create the shipment-event proposal

Markdown turns intended API behavior into a document that collaborators can inspect before implementation. This proposal maps the shipment-event flow into reviewable goals and acceptance criteria.

  • In the Visual Studio Code window from earlier, create a docs folder inside logistics-api-git-lab with the New Folder control if the folder is missing.
  • Create shipment-event-feature.md inside docs with the New File control.

Good. The file sidebar now lists docs/shipment-event-feature.md with a blank editor ready for the proposal.

  • Add the first version of the proposal by replacing the blank editor with the content below:
# Shipment Event Feature

## Visual Flow

```text
API request
    |
    v
Shipment event
    |
    v
Risk scoring
    |
    +--> Optional task creation
```

## Goal

Record meaningful shipment events before evaluating risk and deciding whether a follow-up task is needed.

## Acceptance Criteria

- A shipment event records what happened.
- A shipment event records when it happened.
- A shipment event belongs to one shipment.
- Invalid event data is rejected without creating a record.
- Creating an event can trigger risk scoring and task creation.

What Does This Proposal Capture?

  • Visual Flow shows the processing order from the incoming request to optional task creation.
  • Goal explains why shipment events must be recorded before risk evaluation.
  • Acceptance Criteria gives reviewers specific behaviors to question before implementation begins.
  • Save docs/shipment-event-feature.md with Ctrl+S.
  • Confirm shipment-event-feature.md remains listed directly under docs in the file sidebar.

That is your first complete shipment-event proposal. Its flow now gives reviewers something concrete to discuss.

Can't Find the Proposal File?

Make sure shipment-event-feature.md sits directly inside docs. A second nested docs folder changes the required path.

Help me fix the proposal file path in Visual Studio Code.

Preview the proposal

A rendered preview converts the Markdown source into the document your reviewers read. It also exposes broken headings or damaged diagram spacing before the proposal reaches GitHub.

  • Press Ctrl+Shift+V while shipment-event-feature.md is active to open the rendered preview.
  • Scroll through the preview to inspect the complete request-to-task flow.

You should see the Shipment Event Feature heading above a vertical text diagram. The goal appears above five acceptance-criteria bullets.

Preview Formatting Look Wrong?

Keep shipment-event-feature.md active before using the preview shortcut. Check that the diagram's opening code fence includes text and that its closing fence contains three backtick characters.

Help me fix the Markdown preview formatting.

✔️ Awesome, I've got everything!

Your proposal is saved. Keep its rendered preview available for the branch check that follows.

ⓧ I'd like to double check the full code

Compare your complete docs/shipment-event-feature.md file with this reference.

# Shipment Event Feature

## Visual Flow

```text
API request
    |
    v
Shipment event
    |
    v
Risk scoring
    |
    +--> Optional task creation
```

## Goal

Record meaningful shipment events before evaluating risk and deciding whether a follow-up task is needed.

## Acceptance Criteria

- A shipment event records what happened.
- A shipment event records when it happened.
- A shipment event belongs to one shipment.
- Invalid event data is rejected without creating a record.
- Creating an event can trigger risk scoring and task creation.

What Should Match?

Your file should contain one title followed by the visual flow. The goal and five acceptance criteria should appear beneath it.

Reveal the missing review boundary

Git compares your working tree with the current commit. A status check connects the document you created with the branch that currently contains it.

Before you run the check, do you think the proposal already has an isolated review boundary?

  • Reveal the current branch and untracked changes by running this command in the Visual Studio Code terminal from earlier:
git status --short --branch

What Does This Status Show?

Your branch header still names <default-branch>. The ?? marker identifies docs/shipment-event-feature.md as untracked.

That result is the intended shortfall. The proposal has no isolated review path while it sits on the default branch.

  • Leave docs/shipment-event-feature.md unstaged.
  • Leave docs/shipment-event-feature.md uncommitted.

Don't See the Untracked File?

If the file line is missing, confirm that shipment-event-feature.md is saved directly inside docs. The terminal must still be attached to logistics-api-git-lab.

Help me find why the proposal is missing from Git status.

You have made the default-branch risk visible without committing the proposal. Next, you'll rescue the same file into a reviewable feature branch.

Rescue the Change into Focused Commits

Your rendered proposal made the gap in GitHub Flow visible. The untracked file still sits on the default branch.

A feature branch gives the proposal a review boundary. Two focused commits separate the proposed behavior from its test plan.

In this step, get ready to:
  • Move the untracked proposal onto a descriptive feature branch.
  • Record the initial proposal as its own focused commit.
  • Add the test plan as a second focused commit.
Move the proposal onto a feature branch

The untracked file currently lives in Git's working tree. Creating a branch from the current commit keeps that file available.

  • Create the feature branch from the Visual Studio Code terminal by running this command:
git switch -c docs/shipment-event-feature

What does this command do?

  • The -c option creates a branch from the current commit.
  • The branch name describes the documentation change that belongs on it.
  • The untracked proposal remains in the working tree after the switch.

Git confirms that it changed branches. Your proposal has crossed its first safety boundary without losing any work.

  • Confirm the branch change by running this status check:
git status --short --branch

What does this check show?

The branch header identifies your current branch. The file entry shows that the proposal is still untracked.

You should see docs/shipment-event-feature in the branch header. The untracked docs/shipment-event-feature.md file should still appear beneath it.

Branch did not change?

Confirm that the terminal is still inside the logistics-api-git-lab folder. A terminal in another folder cannot switch this repository's branch.

If the branch name already exists from an earlier attempt, only reuse it when it belongs to this practice clone.

Ask for help with moving my untracked proposal onto its feature branch.

Record the initial proposal

The staging area lets you choose the exact content for the next commit. Staging only the proposal keeps unrelated files outside this snapshot.

  • Stage the initial proposal by running this command:
git add docs/shipment-event-feature.md

What does this command do?

The command places the current proposal in the staging area. Git now knows that this file belongs in the next commit.

  • Check that the proposal is staged by running:
git status --short --branch

What changed in the status?

The proposal now appears as a staged file beneath the feature-branch header. This confirms that the initial version is ready to commit.

  • Record the staged proposal as the first focused commit by running:
git commit -m "docs: define shipment event feature"

Why is this commit focused?

This commit contains one complete review idea. It defines the shipment-event behavior without mixing in the test plan.

The message describes the purpose of that snapshot. A reviewer can understand its scope before opening the file.

The terminal confirms a new commit with the message docs: define shipment event feature. Your core proposal now has its own recoverable point in history.

Commit did not complete?

If Git says there is nothing staged, return to the status output. Confirm that docs/shipment-event-feature.md is listed as staged.

If Git mentions your identity, confirm that the configured name and email from the setup step are still available in this terminal.

Ask for help with creating the first focused documentation commit.

Build the second focused commit

The second commit should capture a separate review idea. The test plan explains how the future API behavior can be checked.

  • Switch back to the editor tab for docs/shipment-event-feature.md.
  • Place your cursor after the final acceptance criterion.
  • Extend the proposal by pasting this section:
## Test Plan

- Submit a valid shipment event and verify it is stored.
- Submit invalid event data and verify the API rejects it.
- Retrieve a shipment and verify its events appear in order.
- Submit a high-risk event and verify the expected follow-up task is created.

What does this section add?

  • The first check covers the successful event-recording path.
  • The second check covers rejection of invalid data.
  • The third check covers event ordering during retrieval.
  • The final check connects high-risk events to follow-up task creation.
  • Save docs/shipment-event-feature.md with Ctrl+S.
  • Switch back to the Markdown preview from earlier.

You should see a new Test Plan section beneath the acceptance criteria. It contains four rendered checks.

✔️ Awesome, I've got everything!

Great. Double check that you saved docs/shipment-event-feature.md before creating the second commit.

ⓧ I'd like to double check the full code

Compare your complete docs/shipment-event-feature.md file with this reference.

# Shipment Event Feature

## Visual Flow

```text
API request
    |
    v
Shipment event
    |
    v
Risk scoring
    |
    +--> Optional task creation
```

## Goal

Record meaningful shipment events before evaluating risk and deciding whether a follow-up task is needed.

## Acceptance Criteria

- A shipment event records what happened.
- A shipment event records when it happened.
- A shipment event belongs to one shipment.
- Invalid event data is rejected without creating a record.
- Creating an event can trigger risk scoring and task creation.

## Test Plan

- Submit a valid shipment event and verify it is stored.
- Submit invalid event data and verify the API rejects it.
- Retrieve a shipment and verify its events appear in order.
- Submit a high-risk event and verify the expected follow-up task is created.
  • Stage the completed proposal by running this command:
git add docs/shipment-event-feature.md

What enters the staging area?

Git stages the saved version of the proposal. This version includes the new test plan.

  • Record the test plan as the second focused commit by running:
git commit -m "docs: add shipment event test plan"

Why use a second commit?

The second commit isolates the verification plan from the initial behavior proposal. Reviewers can inspect either idea as its own change.

The terminal confirms a new commit with the message docs: add shipment event test plan. The proposal now has two clear points in its history.

Second commit missing?

Confirm that the saved file contains the ## Test Plan heading. Unsaved editor changes cannot enter the staging area.

If Git reports no changes, compare the file with the full-code reference above.

Ask for help with creating the separate test-plan commit.

Before you run the final checks, do you expect the branch name and two newest commits to match the work you just completed?

  • Check the current branch and working-tree state by running:
git status --short --branch

What does the final status prove?

The branch header confirms where the commits live. An empty file list beneath it confirms that the working tree is clean.

  • Inspect the newest commit history by running:
git log --oneline

What does the compact log prove?

The compact log places each commit on one line. The newest entries show how the proposal was split into two reviewable ideas.

The status output names docs/shipment-event-feature with no file entries beneath it. The log starts with docs: add shipment event test plan followed by docs: define shipment event feature.

Strong work. Your clean feature branch is ready to become a visual pull request.

Review the Change in a Pull Request

Your proposal now sits in two focused local commits on a feature branch. Those commits are still visible only inside your practice clone.

Publishing makes the branch visible on GitHub. A pull request turns the proposal into a visual diff that collaborators can inspect before implementation.

In this step, get ready to:
  • Publish the local feature branch to GitHub.
  • Open a pull request against the repository's default branch.
  • Inspect the complete Markdown diff.
Give collaborators access

A remote branch gives your local commits a shared home on GitHub. An upstream connects your current feature branch to that remote copy for future pushes.

  • Switch back to the Visual Studio Code terminal from the previous step.
  • Be ready to complete a GitHub authentication request if Git opens one.
  • Publish docs/shipment-event-feature to origin and set its upstream by running this command:
git push -u origin docs/shipment-event-feature

What does this command do?

  • git push sends the two local commits to GitHub.
  • -u records the upstream tracking connection.
  • origin identifies the remote repository linked to your practice clone.
  • docs/shipment-event-feature names the branch being published.
  • Check the end of the terminal output for confirmation that the branch was pushed successfully.
  • Confirm that the terminal reports an upstream connection for docs/shipment-event-feature.

Good progress. Your two focused commits now have a shared remote branch with an upstream connection.

Push rejected?

  • Confirm your GitHub account has write access to the logistics API repository.
  • Complete any authentication request opened by Git.
  • Retry the push after authentication succeeds.

Help me troubleshoot a rejected GitHub branch push.

Open the pull request

The pull request compares your published branch with the branch that receives finished work. This comparison creates the review boundary that your local commits were missing.

  • Return to your logistics API repository page in the browser.
  • Use the branch selector to choose docs/shipment-event-feature.
  • Select Compare & pull request.
  • Confirm the base branch shows <default-branch>.
  • Confirm the compare branch shows docs/shipment-event-feature.

Why does the branch direction matter?

The base branch is the destination for the finished proposal. The compare branch supplies the two commits that reviewers inspect.

This direction keeps unfinished work outside the default branch until the review is complete.

  • Enter Document shipment event behavior in the title field.
  • Summarize the proposed request-to-task flow in the description field.
  • Summarize the four test scenarios in the description field.
  • Select Create Pull Request.

GitHub opens the new pull request titled Document shipment event behavior. You've turned two local commits into a proposal that collaborators can review.

Compare option missing?

  • Refresh the repository page after the branch push finishes.
  • Use the branch selector to choose docs/shipment-event-feature.
  • Confirm the branch exists in the repository's branch list.

Help me find the pull request comparison option.

Inspect the complete diff

Before you open the diff, how many files do you expect this documentation-only branch to change?

  • Select the Files changed tab in the pull request.
  • Inspect the file list for docs/shipment-event-feature.md.
  • Find the Visual Flow section in the diff.
  • Find the Acceptance Criteria section in the diff.
  • Find the Test Plan section in the diff.

You'll see one added Markdown file named docs/shipment-event-feature.md. Its diff contains the visual request-to-task flow.

You'll also see the five acceptance criteria. The four test scenarios appear at the end.

What does this review prove?

The one-file diff keeps the proposal focused. Reviewers can inspect the behavior without searching through unrelated API files.

The complete flow shows what the feature should do. The test plan shows how the future implementation can be checked.

That review boundary is now working. Next, you'll merge the approved proposal and synchronize the result with your local default branch.

Merge and Sync the Finished Change

Your reviewed shipment-event proposal is ready to leave its feature branch. The final GitHub Flow handoff is a pull request merge into the repository's default branch.

GitHub stores the merged history as soon as the review is completed. Your local default branch remains separate until it receives that remote history.

In this step, get ready to:
  • Complete the pull request lifecycle on GitHub.
  • Synchronize the local default branch with the merged history.
  • Verify the finished proposal across both repository copies.
Merge the reviewed pull request

The pull request keeps a visible record of the review. The completed commits become part of <default-branch> after the merge.

Removing the remote branch can feel risky. The branch has finished its job because <default-branch> now contains the commits.

  • Return to the open pull request from the previous step.
  • Select Merge pull request.
  • Select Confirm merge.
  • Select Delete branch.

You'll see the pull request marked as merged. The remote docs/shipment-event-feature branch is deleted.

Is the merge unavailable?

Repository rules can keep the merge control unavailable until the pull request satisfies its displayed requirements.

  • Complete each review requirement displayed on the pull request.
  • Complete each status-check requirement displayed on the pull request.
  • Try the merge again with Merge pull request.

Ask for help understanding the blocked merge requirements.

Close the local synchronization gap

Git tracks local branch pointers separately from GitHub. The local default branch needs the merged remote history before your next feature begins.

  • Switch back to the Visual Studio Code terminal panel from earlier.
  • Return to the branch used before the feature branch by running:
git switch -

What does this command do?

The - shortcut returns to the previously checked-out branch. For this clone, that branch is <default-branch>.

You'll see Git report that it switched to <default-branch>.

  • Bring the merged GitHub history into the local branch by running:
git pull

What does this command do?

Git contacts the configured upstream for the current branch. It integrates the merged history from origin/<default-branch> into your local branch.

You'll see Git bring the merged documentation change into the local default branch. The local copy of docs/shipment-event-feature.md now matches the merged GitHub history.

Did the pull stop?

A pull can stop when authentication is incomplete. It can also stop when a different branch is checked out.

  • Complete the GitHub authentication prompt if one appears.
  • Confirm that the terminal shows <default-branch> as the checked-out branch.
  • Repeat the pull after correcting the branch or authentication issue.

Ask for help synchronizing the local default branch.

Verify both repository copies

The final check confirms that your working tree is clean. It also proves that the local clone contains the proposal shown on GitHub's default branch.

Before you run the check, do you expect Git to report any remaining file changes?

  • Check the synchronized branch by running:
git status --short --branch

What confirms synchronization?

The branch header identifies <default-branch> as the current branch. No changed file entries underneath it means the working tree is clean.

You'll see the <default-branch> header with no modified or untracked paths. Your local branch is clean after the pull.

  • Select docs/shipment-event-feature.md in the Visual Studio Code Explorer sidebar.
  • Switch to the Markdown preview used earlier.

You'll see the shipment-event flow followed by the goal. You'll also see the acceptance criteria followed by the test plan.

  • Return to the GitHub repository page from earlier.
  • Confirm that the branch selector displays <default-branch>.
  • Select the docs folder.
  • Select shipment-event-feature.md.

The GitHub file shows the same rendered proposal as your local preview. Both repository copies now contain the merged documentation change.

✔️ Awesome, I've got everything!

Great work. Your local default branch is clean and synchronized with the merged GitHub pull request.

ⓧ I'd like to double check the full code

Compare your finished docs/shipment-event-feature.md with this complete reference.

# Shipment Event Feature

## Visual Flow

```text
API request
    |
    v
Shipment event
    |
    v
Risk scoring
    |
    +--> Optional task creation
```

## Goal

Record meaningful shipment events before evaluating risk and deciding whether a follow-up task is needed.

## Acceptance Criteria

- A shipment event records what happened.
- A shipment event records when it happened.
- A shipment event belongs to one shipment.
- Invalid event data is rejected without creating a record.
- Creating an event can trigger risk scoring and task creation.

## Test Plan

- Submit a valid shipment event and verify it is stored.
- Submit invalid event data and verify the API rejects it.
- Retrieve a shipment and verify its events appear in order.
- Submit a high-risk event and verify the expected follow-up task is created.

What should match?

This reference contains the complete visual flow. It also contains the goal, acceptance criteria, and test plan.

Your local file and the file on GitHub should match it exactly.

Do the two copies look different?

A different local preview usually means the pull ran on another branch. A different GitHub file usually means the branch selector displays another branch.

  • Confirm that the terminal reports <default-branch>.
  • Confirm that GitHub displays <default-branch>.
  • Repeat the pull after correcting the local branch.

Ask for help comparing the local and GitHub copies.

That's the full GitHub Flow loop complete. Your reviewed shipment-event proposal now lives on the synchronized default branch locally and on GitHub.

Secret mission

Undo a Bad Commit Without Rewriting History

A checked deployment box can make unfinished work look complete. In this mission, you will deliberately commit a false deployment status before restoring the proposal with a visible correction that preserves both events in history.

Clean Up Your Resources

Clean Up Your Resources

The Git and GitHub work from this project costs $0. Choose whether to keep the optional practice branch, pause with the clone untouched, or delete only that branch.

Resources you used:

  • Optional local practice/revert-mistake branch inside the logistics-api-git-lab practice clone.

Keep everything running

No action is needed. Choose this option if you want the local revert example available for future Git practice.

  • Leave practice/revert-mistake in the logistics-api-git-lab practice clone.
  • Keep the merged proposal on GitHub's default branch.
  • Keep the pull request history as the review record for the future API implementation.

Pause - I'll come back to this later

Pausing leaves every file and branch on disk. No process continues running in the background.

  • Close Visual Studio Code.
  • Leave the logistics-api-git-lab practice clone untouched until you return.

Your clean repository remains ready for another GitHub Flow rehearsal.

Delete - I don't want to use this again

This option removes only the optional local practice branch. The merged proposal and pull request history stay in place.

  • Return to the synchronized default branch by running this command:
git switch -

What does this command do?

Git returns to the branch that was checked out before the optional practice branch. This makes the practice branch safe to delete.

  • Use Visual Studio Code's branch management controls to delete the local practice/revert-mistake branch.
  • Open the local branch list again.

You should no longer see practice/revert-mistake in the local branch list.

That leaves your repository tidy while preserving the reviewed proposal and pull request history.

Nice Work!

Nice Work!

Excellent work! You moved a shipment-event proposal through GitHub Flow from an accidental default-branch edit to a merged change. Your repository now preserves a reviewable record of the proposal.

You've learned how to:

  • Create a visual feature proposal that maps a shipment event from the API request through risk scoring to optional task creation. Define acceptance criteria for the behavior. Add a test plan for the future implementation.
  • Use a Git feature branch to move unfinished work off the default branch. Split the proposal into two focused commits with descriptive messages.
  • Publish the feature branch to GitHub. Review the complete visual diff in a pull request. Merge the proposal after reviewing it. Synchronize the local default branch with the merged change.
  • Secret Mission: Create a deliberately wrong commit on practice/revert-mistake. Reverse it with a visible revert commit while keeping the shared-style history intact.

Ready to quiz yourself?