Nordlicht Reisen GmbH, a fictional travel agency, wants to know why the booking site was slower on Monday. The answer lies somewhere between a request from sales, a pull request from Friday and a build that ran overnight. Nobody can find the path. Your task in this lesson: design a work flow in which every change has a beginning, feedback and a trail, and use the tools of both worlds for it.
These are the skills of the exam at the start of the area "Processes and communication": the structure of the work flow (including GitHub flow), feedback loops and notifications (including GitHub Issues), tracking work (GitHub Projects, Azure Boards) and the traceability of source, bugs and quality.
Prior knowledge: The course assumes Git and pull requests (K3, module 3.7 shows them in the daily life of a pipeline). The map of the two tool worlds is in lesson 0.2; accounts and clean-up in lesson 0.1. Branching models in detail (trunk-based, feature branch, release branch) come in lesson 2.1; here the subject is the flow of work, not the shape of the branches.
Note: All statements come from the documentation of GitHub and Microsoft Learn; the pages are listed under "Further reading". The commands and menu paths of this lesson were not run; they come from the reference of GitHub and Microsoft.
The structure of the work flow: GitHub flow
GitHub flow is a lightweight, branch-based workflow. GitHub describes it in six steps:
| Step | What happens | What GitHub says about it |
|---|---|---|
| 1. Create a branch | a branch of its own for the change | a short, descriptive name, so that collaborators can see the work in progress at a glance (examples on the page: increase-test-timeout, add-code-of-conduct) |
| 2. Make changes | commits and a push to the branch | descriptive commit messages; ideally each commit is one complete, single change, so that it is easy to roll back |
| 3. Create a pull request | to ask for feedback | whoever wants feedback before finishing marks it as a draft; linked issues with a keyword close when it is merged; configured checks appear in the pull request |
| 4. Respond to feedback | answer questions and suggestions | further commits; the pull request updates itself |
| 5. Merge the pull request | after approval | conflicts must be resolved beforehand; branch protection rules can block the merge |
| 6. Delete the branch | after merging | shows that the work is finished and prevents accidental reuse; the pull request and the history remain, and the branch can be restored |
Remember the intent behind it: every change has a place (the branch), a space for feedback (the pull request) and a condition for completion (checks and approval). The protection rules themselves, which enforce checks, are taught in lesson 2.2.
The same idea in Azure DevOps
Azure Repos knows the same procedure under other names: branch, pull request with reviewers and policies, merge. The difference lies in the connection to planning: a branch can be created from a work item in Azure Boards, and Azure Boards shows pull requests in the Development section of the work item. Microsoft describes end-to-end traceability as: create a branch from a requirement, review pull requests that are tied to work items, link builds and releases to work items, and follow changes from the requirement to production.