Fix 'Works on My Machine' in Student Team Projects
For student project teams · Based on Sangam Mukherjee DevOps Beginner Blueprint
// TL;DR
Student project teams can use the DevOps Beginner Blueprint to solve the two classic problems of group coding: 'it works on my machine' and overwriting each other's code. Initialise Git at the project root, create .gitignore, and push to a shared GitHub repo as your single source of truth. Enforce a branching strategy where each member works on a named branch and raises a pull request to merge into main. Then Dockerise the app so every teammate and every environment runs identical containers. Git's distributed version control ensures no one overwrites anyone's work — perfect for final-year projects.
Why does our team keep overwriting each other's code?
A team of three building a final-year project hits this constantly: two people edit the same file, one push overwrites the other, and hours of work vanish. The root cause is a lack of version control discipline. Git is a Distributed Version Control System — every developer holds a full copy of the repository and its history locally, and GitHub acts as the single source of truth everyone syncs to.
Start by initialising Git at the project root (not inside a sub-folder — that leaves half your code untracked). Create a `.gitignore` and add `node_modules/` before staging anything, so you don't push thousands of files or accidentally leak an API key your teammate committed. Then push to a shared GitHub repository. Now everyone pulls the same code and pushes their changes back to one authoritative source.
How do we stop stepping on each other's work?
Enforce a branching strategy. Instead of everyone committing to main, each team member works on a named branch — one per feature or per person. When their work is ready, they raise a pull request to merge into main. This forces changes through a review point and lets Git surface conflicts explicitly rather than silently overwriting. Never commit directly to main.
Write clear commit messages that describe what changed and why — 'login validation added', not 'fix'. In a team context, vague messages make the Git history unreadable and impossible to trace when something breaks. The collaboration loop is simple: push your branch to GitHub, others pull to get your updates, and pull requests keep main clean and stable.
How do we end 'it works on my machine'?
The classic demo-day disaster is code that runs on one laptop but crashes on another because of different Node versions, missing dependencies, or OS differences. Docker solves this. Write a Dockerfile for your client and server, then use Docker Compose to run the front end, back end, and database together in one command.
Because every teammate runs the exact same container, the app behaves identically everywhere — your machine, your teammate's machine, and the evaluation environment. This is environment parity, and it turns 'works on my machine' into 'works on every machine.' If you're on Windows, install WSL first with `wsl --install` so the Docker and Linux tooling runs smoothly.
What should our team do next?
Agree on your workflow before writing more code: one shared GitHub repo, a branch per person, pull requests into main, and a Dockerised setup everyone runs. Assign one teammate to set up the repo and .gitignore, another to write the Dockerfiles and docker-compose.yml. Your next step: initialise Git at the project root today and get everyone onto the shared repo before your next coding session.
// FREQUENTLY ASKED QUESTIONS
Do all team members need Docker installed?
Yes, ideally. Docker is what guarantees everyone runs the identical environment, ending 'it works on my machine.' Each member installs Docker (and WSL first if on Windows), then runs the shared docker-compose.yml. This way the front end, back end, and database behave the same on every laptop and in your evaluation environment.
How do we handle merge conflicts as a student team?
Use a branching strategy with one branch per person and pull requests into main. When two members change the same file, Git flags the conflict during the merge instead of silently overwriting. Resolve it together by reviewing both changes in the pull request. This is far safer than everyone pushing directly to main and losing work.
Is DevOps overkill for a college project?
No — the Git and Docker portions specifically prevent the two most common team failures: overwriting code and environment mismatches. You don't need the full CI/CD and Kubernetes pipeline for a class project. Just applying steps 4 through 8 (Git, .gitignore, GitHub branching, and Docker) delivers most of the value with modest setup effort.