You can use git to manage single files spread across your whole filesystem, things that you wouldn't create individual repos. for, but really want to backup / revert sometimes. This does not interfer with regular git repos. in the same file system.
First, create some bash, or similar, aliases:
alias ggit="git --git-dir=$HOME/global_git --work-tree=/"
alias ggitadd="ggit update-index --add"
Then
git init --bare $HOME/global_git
creates a repo. $HOME/global_git - this is like a .git folder, don't look for files in
that folder, the "working tree" where you can see you files is the whole filesystem.
Finally
ggit config --local status.showUntrackedFiles no
Now you can use ggit anywhere as you'd use git normally. In some cases ggit add
may not work as expected, so just use ggitadd instead.
ggitadd .bashrc
ggitadd /data/path/project/docker-compose.yaml
ggit status
ggit commit -am'update config'
To see a list of all managed files:
ggit ls-tree --full-tree --name-only -r dev
You can use this approach to manage those important files you should never commit to a repo. - but don't do this unless you're sure you're comfortable with where you sensitive information is visible.
I have used two sets of aliases, ggit for non-sensitive scripts etc. and the same aliases just
substituting sgit for ggit (and changing the path to $HOME/sensitive_git or whatever).
You can push the non-sensitive repo. to a remote or otherwise backup the $HOME/global_git folder,
and not move the sgit repo. off the machine containing the sensitive data. So the only additional
exposure is the presence of the sensitive data in $HOME/sensitive_git as well as it's original
file-system location. Anyone who can access $HOME/sensitive_git can probably access the original
location too. It's a trade-off, the value of being able to revert changes that broke something against
being mindful extra folder.