Build brief · DevOps
Move one change from an issue to a reviewed merge while keeping history understandable and recovery simple.
Start with the business or technical outcome
A branching strategy succeeds when it reduces coordination cost, not when it has the most branch names. This field lab turns the topic into a small deliverable that can be built, checked and explained. A four-person team needs parallel work, automated checks and peer review without keeping feature branches alive for weeks.
Keep branches short-lived and changes small enough to review. The exact model—trunk-based, GitHub Flow or a release-oriented variant—should follow release constraints rather than fashion. Define one protected integration branch and a clear emergency path.
Use a practice repository with no secrets. Every pull request should link to a requirement, describe test evidence and state risk. A reviewer should be able to understand why the change exists before reading every line.
What to understand before opening the tool
Understand commits, branches, upstream tracking, merge conflicts, pull requests, status checks and the differences among merge commit, squash and rebase approaches. History style is a team decision; consistency matters more than personal preference.
Review is not a ceremonial approval. It checks correctness, maintainability, security impact and test evidence. Automation should remove repetitive checks while humans focus on judgment.
Git
Use it for: create small commits and inspect or recover history Keep as evidence: readable commit sequence
GitHub Pull Requests
Use it for: hold discussion, review and merge evidence Keep as evidence: linked PR with decision
Branch Protection
Use it for: require approved checks or reviews before merge Keep as evidence: ruleset summary
CI Checks
Use it for: run formatting, tests and security-relevant validation Keep as evidence: repeatable check results
The practical outcome is a repository policy, example pull request, passing checks, review trail, merge decision and documented revert test. Build it with fictional, public or explicitly authorised data. Record the starting state before making changes, because a screenshot of the final screen cannot explain how the result was produced. The strongest evidence is a short chain: requirement, action, validation and one reflection on what you would improve.
Build the workflow in six controlled moves
Follow one change through the workflow and deliberately practise a conflict and a revert.
- Open a bounded issueState the problem, acceptance criteria, risk and owner before coding.Checkpoint: Issue linked to the later pull request.
- Create a short-lived branchName it consistently and branch from the current protected base.Checkpoint: Branch reference and clean starting point.
- Commit coherent changesSeparate unrelated work, use descriptive messages and run local tests.Checkpoint: Readable log and local result.
- Open the pull request earlyExplain approach, screenshots or test output, rollout and rollback considerations.Checkpoint: Complete PR template.
- Review and satisfy gatesAddress feedback visibly, rerun automated checks and avoid self-approving protected changes.Checkpoint: Approval and green status checks.
- Merge and test recoveryUse the team strategy, verify deployment input and practise reverting the merged change.Checkpoint: Merge reference and successful revert exercise.
Do not rush through the successful path. Repeat one step with a controlled variation and compare the evidence. That second run reveals which inputs are important and gives you a concrete troubleshooting story for interviews.
Tools, decisions and proof
Make each policy solve a collaboration risk and leave inspectable evidence.
| Decision or signal | Action to take | Evidence to retain |
|---|---|---|
| Unreviewed change reaches main | Required pull request and approval | Ruleset plus approval trail |
| Broken build is merged | Required CI status check | Passing workflow linked to commit |
| Branch drifts for weeks | Small scope and frequent base updates | Short cycle time and manageable diff |
| Conflict is resolved incorrectly | Pair review and rerun tests | Resolution commit and check result |
| Bad merge needs reversal | Known revert procedure | Practice revert without force-push |
Failure tests that improve the project
Workflow rules should protect delivery without turning every small change into bureaucracy.
- Long-lived feature branches: Large divergence creates risky merges and delayed feedback.
- Mixing refactoring and features: Reviewers cannot isolate behavior change or revert safely.
- Approving based on a green check alone: Automation cannot judge every product, security or operational concern.
- Force-pushing protected history casually: Recovery and auditability suffer; follow the team policy.
- Leaving review comments unresolved silently: Record the decision or change so future readers understand the outcome.
Turn the exercise into credible portfolio evidence
Create a small repository policy and demonstrate it with two pull requests: one normal change and one conflict-resolution exercise. Redact identities if needed, but keep the decision trail.
Include a diagram showing issue, branch, check, review, merge and deployment hand-off. Explain why you chose the merge strategy for this team size and release style.
Explain it clearly in an interview
Describe one review comment that changed the implementation, one automated gate and how you would revert a bad merge. Avoid presenting branch names as the main achievement.
Peer review before calling the work complete
Ask another learner to inspect the result without watching you build it. Give them the original scenario—a four-person team needs parallel work, automated checks and peer review without keeping feature branches alive for weeks.—and the evidence pack, but not your intended conclusion. They should be able to trace the input, identify the main decision and locate the proof of the output. If they cannot, improve the labels, timestamps or explanation instead of adding decorative screenshots.
Use this acceptance condition during the review: The requirement, commit, automated checks, review decision and merge are traceable, and the team can undo the change without rewriting shared history. Record one question the reviewer raised and the change you made in response. That small feedback loop makes the Git branching and pull request workflow exercise more credible, easier to maintain and easier to explain under interview questioning.
Questions learners ask
Which Git branching strategy is best?
The best fit depends on release cadence, team size and operational constraints; keep it as simple as the work permits.
Should every commit be perfect?
Commits should be coherent and safe enough for collaboration; the team can use squash or another agreed merge policy for final history.
Can CI replace code review?
No. CI automates defined checks, while reviewers assess context, design, risk and maintainability.
Why practise a revert?
Recovery should be familiar before an urgent production situation, and a revert test reveals hidden coupling.
Use current product guidance
Menus, fields, permissions and service behavior can change between product versions or tenant configurations. Check the GitHub Actions documentation before applying version-sensitive steps in a live environment.
Build the complete skill path
Practise version control, CI/CD, containers, Kubernetes, infrastructure automation, observability and incident learning as one delivery system.
Final perspective
The real value of Git branching and pull request workflow is the ability to complete a controlled task and defend the result with evidence. A learner who can show the input, explain the decision, verify the output and describe one realistic exception demonstrates far more than someone who has only memorised a menu path or definition.