Lesson 2: GitHub Flow and Feedback Cycles

Why a flow of work matters

If you have administered Azure or built apps on it, you have seen how work goes wrong: a fix sits on someone's laptop for a week, a reviewer finds out about a change after it ships, or a bug report says only "it's broken". In the study guide, the first skill under Design and implement traceability and flow of work is about stopping this: design and implement a structure for the flow of work, including GitHub Flow, and a strategy for feedback cycles, including notifications and GitHub Issues.

Think of GitHub Flow as a short conveyor belt. main is always in a state you could deploy. Every change goes onto its own small branch, gets reviewed in a pull request (PR), merges back, and the branch is thrown away. Issues feed work onto the belt, and notifications tell the right people when something reaches them.

One reminder from Level 1: the study guide is Microsoft's own document, free on Microsoft Learn. This course is independent of Microsoft. You need a score of 700 or more to pass.

GitHub Flow, end to end

GitHub's documentation describes GitHub Flow as "a lightweight, branch-based workflow" with six steps: create a branch, make changes, create a pull request, address review comments, merge the pull request, delete the branch. Deployment isn't one of those six steps. In practice, most teams deploy automatically from main once a change merges, so main always matches what is running in production.

Here is the whole loop for issue #42, "Login button misaligned on mobile":

# 1. Start from an up-to-date main
git switch main && git pull

# 2. Create a branch with a descriptive name
git switch -c fix/42-login-button-mobile

# 3. Make changes. Keep each commit isolated and complete so it is easy to revert
git add src/css/login.css
git commit -m "Fix login button alignment on narrow viewports"

# 4. Push the branch and set its upstream
git push -u origin fix/42-login-button-mobile

# 5. Open the PR. 'Fixes #42' links the issue and closes it on merge
gh pr create --base main \
  --title "Fix login button alignment on mobile" \
  --body "Fixes #42. Adjusts flex rules below 480px." \
  --reviewer octo-org/web-team --label bug

# 6. Address review comments: every new push updates the open PR automatically
git commit -am "Use rem units per review" && git push

# 7. Merge once approved and checks pass, then delete the branch (local and remote)
gh pr merge --squash --delete-branch

Sample output from step 5:

Creating pull request for fix/42-login-button-mobile into main in octo-org/webshop
https://github.com/octo-org/webshop/pull/57

Gotcha: closing keywords. close, closes, closed, fix, fixes, fixed, resolve, resolves and resolved only close the issue when the PR merges into the default branch. If the PR targets any other branch, GitHub ignores the keyword completely.

Tip: Use gh pr create --draft to get early feedback. Code owners are not automatically asked to review draft PRs. They are asked once you mark the PR ready for review.

Feedback starts with a good issue

A vague issue is a slow issue. Issue templates in .github/ISSUE_TEMPLATE/ give reporters a structure to follow. They can be Markdown templates or YAML issue forms, which have typed fields and required inputs. Templates only take effect once they are merged into the default branch.

# .github/ISSUE_TEMPLATE/bug_report.yml  (an issue form)
name: Bug report
description: Report something that is broken
title: "[Bug]: "
labels: ["bug", "triage"]       # applied automatically, so triage queries just work
body:
  - type: textarea
    id: what-happened
    attributes:
      label: What happened, and what did you expect?
    validations:
      required: true             # the form cannot be submitted without this

# .github/ISSUE_TEMPLATE/config.yml  (customises the template chooser)
blank_issues_enabled: false      # force people to pick a template
contact_links:
  - name: Support questions
    url: https://example.com/support
    about: Usage questions go here, not in Issues

Labels turn issues into queues you can filter. Create a small, agreed set from the CLI:

gh label create triage --color FBCA04 --description "Needs a first look"
gh issue list --label triage --state open   # the triage rota's daily view

Notifications: signal, not noise

The Watch menu on a repository has four settings:

You are subscribed automatically when you comment on a conversation, are @mentioned, or take part in an issue or PR. GitHub delivers notifications to the web inbox, by email, and to GitHub Mobile.

A design that works in practice:

• The ops team watches Custom → Releases + Security alerts and nothing else.
• Developers stay on Participating and @mentions.
• Review requests are routed with a CODEOWNERS file (in .github/, the repo root, or docs/). The owners are then asked to review automatically, and nobody has to watch everything.
• People are @mentioned as teams (@octo-org/web-team), not individuals, so feedback still arrives when someone is on holiday.

Trade-off: If too many people are on All Activity, notifications become wallpaper and important feedback gets missed. If too few are, nobody sees new issues. Name one triage owner for the triage label.

GitHub Flow or something heavier?

GitHub Flow suits teams that deploy continuously from one production version: web apps, APIs and internal services with good automated tests. It is less of a fit when:

• You support several released versions at once, such as a desktop app or an SDK with v2 and v3 in the field. You need long-lived release branches for those.
• Releases follow a fixed schedule or regulatory sign-off, so merged code waits weeks before it ships.
• Automated tests are weak, so "main is always deployable" isn't actually true yet.

In those cases a heavier model with release branches makes sense. You pay for it with more merging and slower feedback. Branching strategies get full treatment later in the course. For now, the rule of thumb is: the more versions you ship and the slower you release, the more structure you need.

What the exam asks about this

Expect scenario questions such as: "A team deploys a web app several times a day and wants the simplest workflow." The answer is GitHub Flow. If the scenario mentions maintaining multiple versions in parallel, look for a release-branch model instead. You may also get questions on reducing notification noise (Custom watch settings or Participating, plus CODEOWNERS), on making bug reports complete (issue forms with required fields and a config that disables blank issues), and on why an issue didn't close (the PR targeted a branch other than the default).

Key takeaways

• GitHub Flow: branch → commit → PR → address review → merge → delete branch. Deployment is usually automated from main.
• Fixes #N closes the issue only when the PR merges into the default branch.
• Issue templates and forms live in .github/ISSUE_TEMPLATE/. config.yml can disable blank issues. Both take effect on the default branch.
• Use Watch settings (Participating, Custom), team mentions and CODEOWNERS to send feedback to the right people without noise.
• GitHub Flow fits continuous delivery of a single version. Several supported versions or scheduled releases call for heavier flows.