Not sure if there actually is a in scope answer for what you are asking, but the below are some hopefully helpful informations/thoughts.
Besides that, I don’t know about (all) the tools you are mentioning, but thats secondary anyway.
What you want, of course, is to keep the development process, like you described it, alive. As you said, it looks like this:
local dev (start cycle 1) > testing/staging (cycle 1) > production (cycle 1)
This of course isn’t a linear process, it is a cycle. Because after you deployed your work to production you certainly will develop new features based on the latest state you reached, this applies in the same manner for updates – core or plugin.
So if your beginning your new development cycle it would be like this:
local dev (production from cycle 1, start cycle 2) > testing/staging (cycle 2) > production (cycle 2)
This way your code is at the same stage on every step of the way, your version controlling is intact, but of course this is just a simplified draft on how to do it.
After all you want to make git branches for the new features/updates and make use of the version control possibilities in general. So, one more insertion, because of those possibilities the cycle isn’t one dimensional, just thinking of parallel development branches and such.
Anyhow, it boils down to choosing a fitting git workflow, combined with your syncing and backuping needs. As a git branching model or workflow concept is definitely out of scope on here I just leave it at that. Take a look around there is plenty of information about git workflow models out there.
Note: This should be a comment, but I just don’t know how to keep it short.