Welcome to unix.stackexchange.com!
There's no easy answer to your question, and far better people than me have written entire books on the subject of the Linux kernel and operating systems in general.
About the scope of the project: writing an operating system is not a simple task! Even a purposefully minimal OS like Minix is a pretty complex thing! To give you an idea about Linux, think about the C programs you've written so far. The average university coursework tends to be a few thousand lines of C at most. I think my final year project was around 30–35,000 lines of C++. The Linux kernel is roughly 13,000,000 lines of C code.
Why is it all in separate files? Sizeable projects are stored in separate files for logistical and practical reasons. Just consider loading a 13,000,000 line file into an editor! Before tackling a huge project like Linux, you should definitely hone your C skills to the point where the ‘why multiple files’ question answers itself. You should also be able to read C code, not just write it. (harder than it seems at first)
You should definitely be very proficient in C. The kernel is maintained by thousands of people, and you'll be called to understand the personal C idioms of each of them (granted, within the fairly rigid kernel coding standards, but still — everyone has their own problem-solving style).
After you get your C fu, make sure you understand operating systems. This will help you understand the code. Not all of Linux is essential. The kernel proper is pretty small! What bloats it is:
- Thousands of hardware drivers for various devices.
- Abstraction layers for various device classes to simplify APIs and driver writing. E.g., we have the VFS for filesystems, the Event layer for input devices, et cetera.
- Shocking amounts of conditionally compiled code and files catering to the various architectures that run Linux (not every Linux machine is an Intel PC, and some are incredibly different from what you might expect). The kernel has to deal with these differences, and that means more code.
One problem you'll find immediately is that these components aren't so easy to unplug, change and plug back together again. There are numerous interrelations. In short, changing bits of the kernel is tricky.
The reason people suggested Minix to you is simple: it's a full operating system, but it's not burdened by the needs of a system as complex as Linux. The code is small, but still provides full functionality. After all, the first versions of Linux were inspired by Minix.
Sure, Minix has less hardware support these days. So what? That's a boon! Modern computers virtualise very well. Use that to your advantage: a VM to run Minix is so light, it'll make development a dawdle.
If your project is to build an operating system, you could do worse than to start by studying Minix. You may also want to buy and read the book Minix was written to accompany, ‘Andrew Tanenbaum's Modern Operating Systems’.
You should also set your targets and define your terms precisely. If your own definition of an OS is Microsoft's (an OS with a GUI and a full software suite), you may be in for a very long project! Hundreds of thousands of people have worked since the 1960s to bring us where we are now, after all.
Finally, remember the Computer Scientist's battle cry: ‘never reinvent the wheel!’ (we like to make exceptions when learning, of course. And for fun :) )
