To be helpfull, I have written a short controls 101 :)

So the proportional gain is what's used to get the speed of response you require in your system (refered to as "rise time"). If you're rocket isn't correcting quickly enough to avoid going out of control, it's likely the proportional gain needs to be turned up. Unfortunately, one of the consequences of turning your proportional gain that it can begin cause overshoot or make existing overshoot bigger. Also, just as it overshot on the way up, it can also overshoot on the way back down from that overshoot. Thus you get some amount of oscillation as well. You're likely always going to have to accept some small level of overshoot/oscillation, but it can be mitigated somewhat with the derrivative term. You set the proportional gain first to make sure your system has the raw response power to even do what you want to do at all.

As your system approaches the desired setpoint and the error term gets small, the proportional term (which was driving you towards the setpoint) also gets small. This can cause "steady state error", where the system approaches the point you want but never quite makes it there, output sitting steady just off from where you want it. The integral term, which will keep getting bigger while there's still a bit of error, is what is used to crush out this steady state error. You tune this after the proportional term so you're left with a system that gets to where you want at the speed you want it to.

The derrivative term is used like the hydraulic/pneumatic damper in car suspension. When you hit a bump you want the spring to compress and provide resistance and try to restore itself to the uncompressed position. However, a bare spring will tend to over-extend as it releases the energy, pushing the whole car up and giving the passengers a bump anyways, if with a bit of a delay. Once the spring has reached neutral position, the force that keeps it going is inertia because the spring force has gone to zero/is starting to reverse. If you have something that's resisting motion as the spring travels beyond it's neutral position, it will kill the inertia quickly and reduce/prevent the overshoot.

Say your system is approaching the setpoint very quickly (as it often is when it's overshooting). When it hits the setpoint, the error term itself is going to be zero, but the derivative of the error will still be relatively large. When the sign of the error flips, it will suddenly be driving back towards the setpoint (against the overshoot). The proportional gain does this too, but it's slower since the error term is still small despite increasing rapidly.

The derrivative gain gets turned up last, but this is really the beggining of the "compromise" phase. Often you'll find that to get the rise time and steady-state error value constraints you want, your system will have more oscillation and/or overshoot than you want and can be reasonably handled by turning up the derrivative term, which has it's own drawbacks. For instance when you intentionally command a change in setpoint, the error term changes instantaneously, causing the derrivative term to be initially very large. This manifests itself as "derivative kick", and can cause oscillations and overshoot on its own.

This means that you'll either have to a) accept slightly worse constraints for your rise time/steady state error (do you really need them that good to do what you need?), or b) alter the design of the physical systems properties so that it can have a better response to the controller. You'll also want to do bounds checking/enforcing on all your controller terms. This is often best done in terms of the physical properties they describe. For instance, I'll have an acceleration control PID loop controlling the throttle, and then wrap that in a PID loop to control the speed. I can then bound the speed controller to never command more than a certain maximum acceleration to the inner loop. The inner loop is physically bounded by how high the game will let you set the throttle (0-1.0).

The last thing I'll mention (another good reason for bounds checking the terms), is integral windup. If something unusual happens and your system is prevented from moving as the controller commands (this could even be the time it takes your system to overcome static friction if the I gain is to high), the integrator term just gets much bigger than it should to smoothly move the system back to the setpoint. This will obviously cause overshoot/oscillation. Solutions to this are a) bounding the intergral term absolutely, so it just can't get too big and b) being creative about when you allow the integrator in your system to integrate.

I have taken university level controls courses, but using the principles I just described, I have an aircraft taking off and controlling it's speed, roll, and altitude with good response times and relatively low oscillation/overshoot. For low order systems (and systems that can be approximated by lower order systems), there are some formulas to help you get the gains in the ballpark to begin with, but honestly you can probaby use the gains from other people's code as a starting point, at least for the rough orders of magnitude they should be.