Repository navigation
Workflow Retrospective
This page documents the deviations from the required GitHub workflow that occurred during the project, in line with the "Making Mistakes" guidance in the assignment brief. We have recorded these openly so the marking team can take the context into account.
| # | Issue | Phase | Status |
|---|---|---|---|
| 1 | No issue-linking, no forks, missing Snyk setup | Initial setup | ✅ Resolved |
| 2 | PRs merged without squashing | Early implementation | ✅ Resolved |
| 3 | Mismatched branch naming convention | Ongoing | ✅ Resolved |
| 4 | Missing change-summary file for a PR | Application card component | ✅ Resolved |
During the initial setup phase — covering repository creation, tech-stack scaffolding, and Supabase backend setup — the team had not yet adopted the required workflow.
Specifically:
-
No linked issues. Setup work was completed without being tied to a corresponding issue. This affected:
-
PR #1— repo-setup -
PR #12— supabase-setup - The earliest commits to
main(initial commit, Update README.md)
-
- No individual forks. Branches were created directly on the main repository rather than on individual team members' forks.
-
Direct pushes to
main. Some of the very first commits were pushed straight tomain, bypassing branches and pull requests entirely. - Missing Snyk integration. Although Snyk was required from the start of the project, it was not configured during initial setup and has only recently been added. Snyk now actively monitors dependencies for known security vulnerabilities and may open pull requests with recommended fixes. All Snyk-generated PRs are still reviewed, tested, and approved before merging — no exceptions.
These changes occurred while the team was still standing up the project and learning the required workflow. The priority at that stage was getting a working repository and a running tech stack in place — the issue-linked, fork-based process had not yet been established across the team.
From this point forward, all work follows the required workflow:
- Every change begins with an open, team-approved issue carrying appropriate labels.
- Each member forks the upstream repository and creates feature branches on their own fork, branching from
main. - All changes are submitted as pull requests from fork to upstream
main, reference their associated issue (e.g. "closes #123"), and are reviewed and approved by another team member before merging. - Commits are squashed and conflicts resolved prior to merge.
The setup work described above is treated as a one-off learning phase. With the repository and backend now in place, our team continues to implement the application's features using the correct workflow.
After adopting the workflow above, our team identified that some pull requests had been merged using regular merge commits instead of the required Squash and merge option.
This was an oversight while the team was still becoming familiar with GitHub's merge controls.
Our team has clarified that all future pull requests must be squash-merged after approval, so that each contribution appears as a single, clean commit on main. This keeps the commit history readable and makes it easier to trace each change back to its originating issue.
As the project progressed, our team noticed that some branches did not follow the required feature/feature-name naming convention. The affected branches were:
read-me-update38-save-state8-sidebar17-css-presets
This resulted from miscommunication and human error — naming conventions weren't consistently reinforced across the team early on.
Going forward for A2, our team will strictly follow the correct branch naming convention for every new branch, and branch names will be checked as part of the PR review before merging.
While working on the application card component, the markdown file summarising the changes was not created before the PR was submitted, as required by the team's workflow. As a result, that change is documented only through the commit history and PR description, rather than the dedicated summary file.
Going forward, a change-summary markdown file will be created for every issue before its PR is submitted, in line with our team's existing workflow. This ensures each merged change has clear, standalone documentation independent of the Git history.
These deviations were all identified and corrected by our team during A1. We've documented them transparently to reflect our learning process and to demonstrate that, from this point forward, every contribution follows the full required workflow: issue → fork → feature branch → PR → review → squash merge. Thank you for taking this into consideration.