Earlier quoted context omitted.
EnvKey[1] can help with process reloading, and can facilitate both restarts and hot reload updates. (Disclaimer: I’m the founder.) The pros/cons of environment variables vs. files (or other approaches) is also something I’ve thought about a lot while working on EnvKey. We use environment variables as a default approach, since it seems to be the most common way to pass secrets/config to a process in the wild and we wa…
EnvKey looks great! Only one thing strikes me as unfortunate, which is it seems like it fragments the development process because now your code history is tracked in git but your config history is in EnvKey. It means everything I do is duplicated (for example, tags, branches etc). It isn't clear to me how I would take, for example common operations such as rebasing one git branch on another and replicate the same on…
I definitely see your point on splitting up the history!
One thing to consider though is that you're already forced to split up the history in order to handle secrets securely.
Given this unfortunate truth, I think you're better off storing all the config and secrets together rather than splitting them up and keeping config with the code.
There's not always a clear line on what's a secret and what's "safe" config, so attempting to split them up like this is asking for trouble: you're almost guaranteed to end up with secrets in your git repo eventually.
All that said, we've thought about adding a git integration that would output a non-sensitive state file ala 'tfstate' so that you can see your EnvKey history baked right into your git history--it wouldn't show values but you could see what keys had changed. Would something along those lines help to address your concern?