As a SF Developer, we have processes when it comes to this type of thing you're describing, firstly we do not use staging for direct changes to the system rather we create new sandboxes with referenced Jira ticket numbers (e.g. SALLY-369).
I'd like to also mention that we have data and metadata which I hope you're familiar with; when we get a ticket that is just a data change we do it straight into staging, and then once we get the all clear we create whatever it be into the live system
Secondly, I'd like to explain the whole pushing process at least for our company when a ticket is created we create a new sandbox that is a direct copy of staging but in no way affects staging, we then make the changes in the newly created sandbox when the changes are made in the sandbox and get the go-ahead to push into staging for testing we only use staging for testing/stakeholders
Now the reason we do this is due to things being overwritten if changes are made DIRECT into staging which is inefficient and overall bad practice.
Now production, I assume you're talking about the live system (as production can be staging or live as they're under the same category) Live is an out of date version of staging, we want this though, as Live is customer facing we have releases which happen every few weeks ( this is where the staging date is analysed and deemed good to go) and thus is then pushed into live.
This is how the whole process goes, don't worry about int, its just a derivative of staging that is the first step into building into staging:
- 1. Sandbox
- 2. int
- 3. staging(UAT/production)
- 4. Live (production)
I hope this clears things up for you if not, reply to this and I'll be happy to explain in more detail for you.