Version Control and Release for a Student Software Project
A Year 12 team of four is building a booking system for the school gym. They currently share one folder on a network drive and edit files directly; twice this term one student's work was overwritten. The team must deliver a working version to the gym manager every two weeks and keep a stable version available at all times. One student wants to use a single shared branch and commit directly to it. Another wants a feature-branch workflow with pull requests. The teacher will mark the final product and needs to see who changed what.
1. Recommend a workflow and justify it against the team's constraints: no lost work, fortnightly releases, always-stable version, and visible authorship.
Read the worked answer
Feature-branch workflow with a protected main branch. Each student works on a branch named for the feature, opens a pull request, and at least one teammate reviews before merge. Main is always stable and is what the gym manager receives every two weeks via a tagged release (e.g. v1.0, v1.1).
Why not a single shared branch: it recreates the overwrite problem, makes review impossible, and a broken commit reaches the stable version. The branch model gives isolation, review, and a clean history. The tag records exactly what was delivered. Authorship is visible in commits and PRs, satisfying the marking requirement. Cost: small overhead of PRs, acceptable for four students over a term.
2. A student commits a file containing a real database password. Describe the immediate response and the process change to prevent recurrence.
Read the worked answer
Immediate: treat the password as compromised and rotate it at the database. Remove the secret from the current code and from history (rewrite or use a secret-scanning tool), because deleting it in a later commit leaves it in earlier history. Notify the team and the teacher.
Prevention: store secrets in environment variables or a local config file excluded by .gitignore; add a pre-commit hook or CI secret scan that blocks commits matching patterns like 'password=' or key formats; document the rule in the repo README. The team should also review the PR template to include a 'no secrets' checklist item, since review is the last line of defence.
3. The gym manager asks for a change two days before a release. Explain how the team should handle it without breaking the stable version.
Read the worked answer
Do not commit directly to main. Create a branch for the change, implement and test it, and have it reviewed. If it is ready and safe, merge and include it in the release; if it is risky or incomplete, leave it on the branch and ship the current tagged version to the manager, explaining the change will follow in the next release.
The stable version is whatever main points to at the last tag, so it is never at risk. The team should record the request as an issue so it is tracked. This protects the fortnightly commitment while still being responsive.