Regular commits to IRP repositories#
You are expected to stay actively engaged with your Independent Research Project (IRP) throughout the summer. Keeping your project version controlled with frequent, well‑described commits is not merely a good practice - it is a safeguard that could provide evidence of consistent engagement throughout your IRP. A detailed, time‑stamped history is the first line of defence if an examiner questions authorship. It also lets supervisors see problems early and offer targeted help.
Frequency – commit and push after every meaningful chunk of progress (about once or twice each working day). This rhythm normally produces at least one substantive commit per week.
Commit messages - each commit message must explain what changed and why. Brief, empty or token messages (e.g. “update”, “fix”, “add file”) undermine the record.
No “mega‑commits” – delivering a single, end‑of‑project or end-of-month commit with many files and no development trail to demonstrate the evolution of your project is a red flag and may trigger an academic misconduct investigation.
Branching – commits do not need to be made directly to the main branch. You may commit and push to any branch as appropriate for your workflow.
Scope & confidentiality – version‑control everything you can: code, Jupyter notebooks, data processing scripts, LaTeX/Word drafts. For confidential work, covered by an NDA, discuss solutions with your IRP supervisors. If your work is not confidential or covered by NDA, it must be version controlled, committed and pushed to your IRP repository.
Cloud-based work – if you work in a cloud service such as Google Colab, this does not replace the need for version control. You must regularly commit all relevant files (e.g. Jupyter notebooks, data processing scripts, outputs) to your IRP repository to maintain a clear project history.
Commit pattern – splitting a larger part of the work into multiple chunks and committing them separately to artificially simulate a gradual development is not allowed. This tactic is easy to detect and will be interpreted as an attempt to mislead reviewers about how the project evolved over time. Such behaviour is considered suspicious and may trigger an academic misconduct investigation.
Large files – large files such as raw or processed data files, simulation results, and high-resolution visualisation outputs should not be stored directly in the repository. These can be uploaded to your university-provided OneDrive, and a link to the relevant folder can be included in the repository README. However, all code required to generate these outputs must be included in the repository to preserve the reproducibility and transparency of your work.
Written reports – the project plan and final report must be version controlled in the same way as everything else. If you are working in Overleaf or MS Word, you are expected to regularly download and commit the relevant files to your repository — for example, the .tex, .bib, and figure files for LaTeX, or the .docx file for Word, at least once per week.
Reproducibility – your IRP must be fully reproducible. You are expected to make every reasonable effort to ensure that any result, figure, analysis, or output presented in your written report or during the viva can be independently reproduced. This means all necessary files — including code, scripts, configuration files, and any supporting resources — must be included in the repository. If any data or files are stored externally (e.g. in OneDrive due to size), clear links and usage instructions must be provided at relevant places.
We take academic misconduct very seriously. A well-documented version history can be important evidence in demonstrating that your work is genuinely your own. In the event of any allegation, such as the use of generative AI tools to generate large parts of your code or outsourcing your work (e.g. delegating your work to somebody or something else), a consistent and authentic commit history could help you demonstrate academic integrity.
We understand that there may be weeks when you cannot make progress due to technical challenges, illness, or taking time off. You do not need to notify us in those cases. We will not monitor your commits in real-time, but we may decide to review them at any point to understand how your work evolved, particularly if concerns of academic misconduct arise.
If you are working on a confidential external project, which is covered by an NDA, and cannot use the IRP repository due to confidentiality restrictions, we will rely on your host organisation’s oversight and expect them to flag any suspected cases for us to investigate. For any IRP, written reports must be version controlled and committed regularly to the IRP repo.
Manipulating Commit History#
Modifying the commit history (including but not limited to squashing, force pushing, or altering previous commits) without clear justification and explicit approval from the module coordinator is strictly prohibited. The commit history serves as an important record of your project development and must remain intact to maintain academic integrity and allow proper assessment of your work progression.
If you believe that there are exceptional circumstances that require commit history modification, you must contact the module coordinator before making any changes and receive written approval.