The Problem I Noticed
When I started my Computer Science degree, I noticed the same pattern playing out across the cohort. Some students were spending hours building elaborate folder structures to organise their notes and materials. Others were just dumping everything onto their desktop and hoping they could find things later. Most people fell somewhere in between.
The bigger issue was that everyone was doing this separately. We had almost 30 students all trying to organise the same lecture notes, the same lab exercises, the same revision materials. When someone found a useful resource, they would share it in WhatsApp, and then everyone would save it in different places with different names. Materials got lost. Updates got missed. It was a lot of wasted effort.
The situation got even more inefficient when one of our lecturers only sent materials through Telegram. A student would have to DM the lecturer on Telegram to get the file, and then we would all wait for that student to share it in the WhatsApp group. It was unnecessarily complicated.
For students who struggled with organisation, this became a real problem. They would spend time searching for materials instead of actually studying them. Some just gave up on trying to stay organised at all.
I was already using Git for my coursework and personal projects, so this inefficiency stood out to me. The same tools I was using to manage code could solve this problem for everyone.
Why I Built It
I come from a background of five years in development (mostly full-stack work with a focus on security) and six years in sales before that. When I see an inefficiency, my instinct is to build a solution rather than accept it as inevitable.
I was already using Git for version control on my assignments. The same principles that make Git valuable for code also work for study materials: version history, distributed backups, structured collaboration, and easy synchronisation.
So I created uwe-cs-2026, a GitHub organisation for my cohort. The idea was simple: instead of everyone maintaining their own scattered collections of files, we could have one structured repository for each module where everyone contributes and everyone benefits.
I also saw this as an opportunity to help other students in my cohort get comfortable with Git early on. Git is basically your bread and butter if you are in tech, so getting hands-on experience with it through something practical like managing study materials made sense. Rather than waiting until they need it for a group project or internship, students could start building that muscle memory now.
How It Works
The structure is deliberately straightforward. Each module gets its own repository with a consistent folder layout:
module-name/
├── notes/
├── labs/
├── assignments/
├── revision/
└── resources/
This gives us a single source of truth for each module. When someone adds useful notes or figures out a tricky lab problem, they can commit it to the repository. Everyone else just runs git pull and gets the latest materials instantly.
No more asking in the WhatsApp group if anyone has the notes from last week. No more waiting for someone to DM a lecturer on Telegram and then forward files to the group. No more downloading the same file five times because you cannot remember where you saved it. Everything is in one predictable place with a predictable structure.
The Benefits I Did Not Expect
The most compelling advantage turned out to be something I had not really thought about initially: built-in redundancy.
Unlike a shared Google Drive folder that exists in one place under one account, Git creates distributed backups automatically. Every student who clones a repository has a complete copy of all the materials on their own machine. If someone accidentally deletes something from GitHub, anyone with a local clone can restore it. If I graduate and stop maintaining it, someone else can fork it and keep it going.
This is resilience that comes free with Git's architecture. We get distributed redundancy without having to think about backup strategies.
The other benefit is that using Git for this gives people practical experience with version control, collaboration workflows, and distributed systems. These are skills that will be valuable throughout a CS career anyway, so learning them while managing study materials makes sense. Students get comfortable with cloning, pulling, committing, pushing, and submitting pull requests in a low-stakes environment where mistakes are easy to fix.
What Goes Where
Git works best for text-based materials: Markdown notes, code examples, configuration files, documentation. For large binary files like lecture recordings, we still use Google Drive and just add links to the recordings in the appropriate repository.
This keeps repositories lightweight and fast to clone while still providing access to everything we need.
Collaboration and Contributions
I set this up so that any student can contribute. People can fork repositories, add improvements or new resources, and submit pull requests. This creates a light review process where we can check contributions before merging them.
The main guideline is simple: keep contributions clear, well-organised, and relevant to the module. Do not upload copyrighted university materials that we are not supposed to redistribute. Focus on student-created notes, summaries, code, and study aids.
Why This Matters Long-Term
My goal is not just to help people pass first-year modules. I want to build a knowledge base that accumulates value over the entire degree programme.
As we move into second and third year, we can keep adding materials. Advanced algorithms, project work, dissertation resources, whatever turns out to be useful. The organisation becomes a comprehensive archive of cohort knowledge.
After graduation, it stays accessible. If I need to reference something from a second-year module or refresh my memory on a particular topic, I can pull up the exact notes and code examples I used during the course.
This creates compounding value over time. Unlike individual note collections that get abandoned after graduation, a collaborative repository keeps serving as a reference.
Practical Impact
The feedback I have gotten from classmates has been positive. People appreciate having one clear place to look for materials instead of digging through WhatsApp chat history or trying to remember which cloud folder something was in.
For students who were struggling with organisation, this provides structure they can follow without having to build it themselves. For students who were already organised, it reduces duplication and makes it easier to share what they have built.
For students who were new to Git, this gives them a practical reason to learn it. Instead of Git being an abstract concept covered in a lecture, it becomes a tool they use regularly to access materials they actually need.
It is not a complex technical project. It is just a straightforward application of Git to a common problem. But that simplicity is what makes it work.
How Others Could Do This
Any cohort in any technical discipline could replicate this approach. The barrier is not technical skill but initiative. Someone needs to set it up, explain why it is useful, and get people contributing.
The initial setup took me a few hours: creating the organisation, setting up the first few module repositories, writing the README with guidelines, and getting the word out to classmates.
Ongoing maintenance is minimal. I review pull requests occasionally and make sure the structure stays consistent, but most of the value comes from students contributing their own materials.
If you are in a similar situation where your cohort is dealing with scattered files and duplicated effort, this is worth considering. The tools are free, the setup is straightforward, and the benefits compound over time.