Combining multiple CSS files without conflicting code?

That's the beauty of the cascading part. The key is to make sure you load the css pages in the right order. First, load normalize.css. Then load common.css (rules that are common to all or most of the pages) -- you need this so you don't repeat yourself (DRY). Then load the specific.css file that is different for each page. Since a rule in the latter will override a similar rule in the former, it will work fine. One difficulty is remembering to put common rules in common, rather than in the specific file. If you have to make a change (always) you only want to make it in one place.

Why do you feel you need to combine them on deployment? It's certainly not necessary. I can't think of any good reason for ever doing it. It has huge downsides in terms of on-going maintenance, errors, duplication. Every time you make a change you would need to update your index.css. Sounds like a nightmare. I agree with you when you say "a lot of potential issues" and "not worth trying". There's enough to keep us busy without work like you are suggesting.

If you check practically any production website you will see that they have more than one external css file. Some I've checked have many more than several, and I haven't checked very many.

The short answer is yes. So you have two problems here, and when you separate the two and attack them appropriately, this won't be so bad.

First, lets talk about the possibility of conflicting header classes, or some other conflict if you combine multiple css files into one. There isn't a build system to prevent this. Instead, this is really just an immature or non-existent naming convention that you as the develop(s) are using. Which this is a common problem, so there are a lot of ideas on naming conventions. There are 3 big acronyms floating around today, that provide a set of "rules" or ideas about how you should name elements. SMACSS, OOCSS, and BEM are the three. I encourage you to look up a bit about all 3. I personally steal bits and parts that I like from them, but I don't follow any religiously. But if you have multiple .header classes that need vastly different styles, you have a naming convention problem. Fix that, and you'll fix any potential conflicts and bugs.

As far as combining css files into one, it's time you started looking at, and using css pre-processors. 3 pre-processors exists, LESS, Sass, and Stylus. I use Sass exclusively, and Sass is the one treehouse has lessons on. Sass is likely the most used. It's also the one I use.

Sass has a lot of features too it. It allows you to have functions, variables, and things called mixins into your css code. It lets you write logic in the css. When you use sass, you'll write your css as a .scss or a .sass file extention, depending on the markup you're using. I use the .scss version personally, which is closer to css.

Now, you can your multiple css files as sass files, and than @import them into one big sass file, that can be compiled by Sass for you into one big css file. @import in Sass doesn't have the same performance hits as it does in CSS, since the compile happens at build time, not at the load time, it's perfectly fine to use. Valid CSS in a Sass file is perfectly valid Sass, so you can write pure css if you want, and just let Sass combine all the files for you, or you can start to explore and use some of the Sass niftyness.

So combine a better naming convention with some Sass, and you'll like where you are at today. I don't start a project anymore today without Sass, it's that powerful. I haven't written a vanilla CSS file in well over a year.