So, like most servers that have their own plugins, I have Jenkins - lovely CI that it is. Whenever anyone pushes something to a master branch, Jenkins builds it - like normal. And then something a little less common... Jenkins pushes the files to my server for use. How it works is that for the plugins that all my servers use, I drop them into $STORAGE/all And for plugins that only a few users use, it goes $STORAGE/$SERVERNAME The plugins just sit there, until it's time for the server to restart - then, prior to the server starting, I have all of the plugins copied to the server's plugin directory. This way, I can update plugins as often as needed - and whenever I, or someone else, decides to restart the server... everything is updated. While I'd normally drop the plugin into the server's plugin directory directly, I've learned that it is an unwise practice... and so I don't. This works just fine, and is something I'd like to continue to do. Problem now, however, is that I'm opening the doors for others to work with me in keeping a server online, functional, and updated. However, I've seen what mistakes I can make that give me headache.... I don't really care to deal with the mistakes of others, without knowing exactly what they changed, when, and ideally why. So ... git. I've made a repo for everything that is my server, other than the world files. This'll allow someone to push to the remote repo, and then a post-receive hook can trigger my server to do a # git pull and update. Neat, right? Here's the problem... The external modification of plugin files (The copying of plugins on restart, earlier mentioned) just seems like it'd start causing conflicts as soon as someone else starts making changes. Right now it's fairly simple for me to avoid, I do a commit and push each restart. Works well enough. But my instincts tell me I'm missing some sort of failsafe here, to prevent some sort of muck-up. I'm hoping an additional set of eyes and experience can tell me what I'm missing here.