L1. Flow of Work and Traceability: GitHub Flow, Azure Boards & Work Item Integration
GitHub Flow keeps main always deployable through short-lived feature branches, and AB# syntax plus the Azure Boards GitHub Connector link every commit back to the work item that justified it.
What Is GitHub Flow?
GitHub Flow is a lightweight branching model that keeps the main branch always deployable. Unlike Git Flow, which maintains multiple long-lived branches (develop, release, hotfix), GitHub Flow uses only main and short-lived feature branches.
The workflow is straightforward: create a feature branch off main, commit changes, open a pull request for review, merge after approval, and delete the branch. Every change requires a pull request before merging to main. This ensures code review happens before production code changes and main is never broken.
Why Traceability Matters
Traceability answers the question: "Why did this code change, and what work item justified it?" For audits and compliance, you need a complete chain from requirement to code to release.A full traceability chain looks like this:
- User story or bug work item
- Feature branch created for that work item
- Commits referencing the work item ID
- Pull request linking the work item
- Build and test pipeline run
- Release containing that code
Without traceability, auditors cannot verify that changes follow proper change control processes.
Linking Work Items in Azure Boards
Azure Boards integrates with GitHub through the AB# syntax. When you include AB#123 in a commit message or PR description, Azure Boards automatically links that change to work item 123:
git commit -m "Fix authentication flow AB#456"The commit now appears on work item 456's timeline. Teams can also create branches directly from a work item in Azure Boards, and the branch name is pre-populated with the work item ID for easy reference.
GitHub Issues and Closing Keywords
When using GitHub Issues instead of Azure Boards, use closing keywords in PR descriptions to auto-close issues:
| Keyword | Behavior |
|---|---|
| Fixes #123 | Closes issue 123 when the PR merges |
| Closes #456 | Closes issue 456 when the PR merges |
| Resolves #789 | Closes issue 789 when the PR merges |
The Azure Boards GitHub Connector
The Azure Boards GitHub Connector bridges the gap between a GitHub repository and an Azure DevOps project. Once configured, every commit and pull request on GitHub automatically appears on the corresponding Azure Boards work item's timeline without any manual linking.
This allows teams to use GitHub for code while maintaining sprint planning and work tracking in Azure Boards. The connector handles the linking automatically, reducing manual overhead and keeping both systems in sync.
Feedback and Notifications
GitHub Flow supports asynchronous collaboration through notifications. Team members receive alerts when:
- A pull request is opened requesting their review
- Comments are added to an issue or PR
- Their review is requested or dismissed
These notifications keep stakeholders informed without requiring them to switch between tools constantly. Exam tip: The AZ-400 exam tests traceability chains and the relationship between GitHub Flow, Azure Boards, and compliance. Remember: GitHub Flow makes main always deployable through short-lived branches and PR reviews, while AB# syntax and the Connector enable full work item tracking.
- ✓GitHub Flow keeps main always deployable: every change goes through a short-lived feature branch and a pull request before merging back to main
- ✓The AB#123 syntax in a commit message or PR description auto-links that change to Azure Boards work item 123
- ✓GitHub closing keywords like Fixes #42 or Closes #42 in a PR description automatically close the referenced issue when the PR merges
- ✓The Azure Boards GitHub Connector links a GitHub repository to an Azure DevOps project so GitHub commits and PRs appear directly on the linked work item's timeline
- ✓A full traceability chain (requirement to work item to branch to commit to PR to build to release) is what auditors look for when verifying change control, not just code review approval alone
1. A team wants every commit that resolves a bug to automatically link back to the Azure Boards bug work item without any manual step. What should they do?
2. A GitHub-hosted repository needs its pull requests to show up automatically on the corresponding Azure Boards work items used for sprint planning. What enables this?
3. Why is GitHub Flow considered simpler than Git Flow for teams practicing continuous delivery?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.