Technical coursework
Organise a coursework repository before the first commit
A repository can make a programming assignment easier to track, but it can also expose work if its visibility and contents are chosen casually. Begin with the module's instructions on collaboration, submission and publication. The fact that code belongs to you does not automatically mean the assessment permits a public repository while the work is in progress.
GitHub's documentation explains repository creation, commits and access controls. Use those technical features within your university's academic and data-handling rules. This guide helps you organise a permitted repository; it does not authorise sharing solutions, restricted datasets or credentials with classmates or the public.
We may earn a commission from retailer links. This guide does not claim first-hand product testing. Our editorial approach
Confirm the required location
Check whether the course provides a repository through its own organisation or expects you to create one. Follow the specified route and account requirements. Do not duplicate an assessment into a personal public space simply because you are more familiar with it. Ask the module team if the intended repository is unavailable.
Record who should have access and what the submission process actually uses. Some courses assess a particular commit or branch; others require an archive or separate upload. Keep that instruction in your project notes. A successful push is not automatically a completed assessment submission unless the course says it is.
Define what belongs in the project
Put source files, appropriate configuration and a short README in a clear project folder. Identify generated output, large local dependencies and private configuration before the first commit. Use the course's ignore rules where supplied and inspect them against the actual files. An ignore file is not a substitute for checking what you are about to add.
Keep passwords, tokens and restricted data out of the repository. Follow the university's approved method for any credentials the coursework requires. If you discover that sensitive material has already been committed, contact the responsible support team and follow its incident process. Deleting a file from the latest view does not necessarily resolve its earlier exposure.
Make the README useful
Explain what the project does, the expected environment and how to run the permitted example. Name required inputs and where they come from without embedding private access information. Include any setup steps the marker needs under the assessment rules. The README should help another authorised reader begin without guessing your laptop's folder layout.
Keep it proportionate to the project. A short exercise needs a clear explanation, not a large badge collection or unsupported claims about production readiness. Update the instructions when the run command or required files change. A polished README describing an old version can be more confusing than a plain one that accurately describes the current work.
Commit changes with a purpose
Review the files and differences before making a commit. Group related changes so the message can say what changed and why. This helps you revisit a working point and explain the development process. Avoid using a long series of meaningless messages that provide no clue which change fixed an observed problem.
Follow the module's approach to branches and collaboration. If group work is allowed, agree how changes are reviewed and combined. Do not assume that a classmate may contribute to an individual assessment because the platform makes collaboration easy. Keep the technical workflow aligned with the actual academic instructions.
Verify the submission state
Before the deadline, inspect the remote repository under the intended account and confirm that the required commit is present. Test the project from a clean permitted copy when practical. Check that supporting files are included and that local paths do not conceal missing dependencies. Record the submission reference required by the course.
After assessment, check the course's rules before changing visibility or using the work in a portfolio. Retain appropriate attribution for permitted external material. New hardware is only needed for a demonstrated course requirement; reliable repository work is primarily about controlled contents, understandable history and a submission another authorised person can reproduce.
Your next steps
- Confirm course sharing and submission rules.
- Inspect contents before the first commit.
- Keep credentials and restricted data out.
- Verify the required remote commit and runnable files.
Sources and further help
Sources were consulted on 5 September 2026. Provider terms and services can change; check your exact booking, product or university service.
Keep planning
- Check MATLAB access before choosing engineering course equipment
- Prepare a Jupyter notebook that a marker can follow
- Import coursework CSV data without changing identifiers
- Prepare Autodesk student access before design classes begin