There are a few main ways to handle dependencies:
1) Make the scripts handle their own dependencies.
This seems to be what you're doing, and is how most beginner programmers first learn to handle dependencies. It is probably the most intuitive way to do it, to a programmer familiar with passing parameters to methods, but not familiar with other methods of dependency handling.
As you are finding out, it quickly becomes apparent that it has many limitations on anything more advanced than classroom assignments or the simplest kinds of applications.
2) Dependency-handling using Singletons - The art of making scripts with a simple global access point, responsible for holding all the dependencies throughout the project.
This is usually done using singletons as holders, and then "pulling" references from those singletons using
Singleton is the
type of the class.
instance is a
static field in that class, holding a reference to an (the only) instance of that class.
dependency1 is a field holding a reference to one specific dependency.
You will often hear that "singletons are evil" or that "you should never use singletons". Don't blindly trust such statements. As often is the case where similar generalized statements are involved, things are not so black-and-white.
Singletons do have their use-cases, and, although there are better methods for handling dependencies, singletons are a valid method, and they are an important stepping-stone to understand why other, better methods, are better.
I personally use singletons for many of my small-scale unity projects; finding more advanced methods more time-consuming for "advantages" that would never be used/required (aka overkill).
This is pretty much the experienced programmers' standard way of handling dependencies. It does, however, present a steeper learning-curve in general (nothing too complicated, but you probably don't want to learn this while at the same time learning to make your first games).
Additionally, for Unity specifically, there are some caveats, which make DI really not appropriate for your first few projects. And if you don't step through dependency-handling based on singletons first, you will know what to do, but most likely, you will be doing DI without knowing why it's (most but not all times) better to do dependency-handling this way.
The easiest way of doing DI for Unity, at least to my knowledge, is like doing DI for any other project: Use a DI framework.
In Unity's case specifically, the one I have experience with and recommend is Zenject. You can also find explanations for everything I mention here on the Zenject project page. From the theory behind DI, to the caveats related to Zenject (and DI in general) on Unity.