I have a main template like website I have made that will allow me to quickly roll out and make new websites on demand when I need them, for my personal use.
I’m wondering what is the best practice when using a Git repo is for this practice. My goal is that if for example down the road I’d like to make a change to all the sites at once, I can simply change the master (Repo) and have this change applied to all other versions of the template.
Currently I have my template hosted privately on BitBucket. I’m assuming it is best to git clone the repo, and then makes changes on the clone. Then when I make changes to the template I do a git pull on the sites. Is this is the ideal approach, or are there better methods to do this?
2
What you might want to look at is multiple repositories here forked off of a main development template line. This lets you keep some centralized templating while letting the downstream projects keep a bit more in control of their own destiny — including holding patches to the core if you need to roll that way.
We used a strategy like this for a half-dozen or so wordpress sites to great effect, we could get worpdress security updates deployed across all projects in minutes. I will echo @Aaronaught here — unless you are very disciplined in the way you develop the core template this will be tricky to pull off. WordPress, over the years, has got that discipline so it worked out great there.
3
I think you’re confusing the role of source control with the role of software architecture and proper dependency management.
If you’ve got a templating system, or just a template, that you want to be able to roll out to multiple sites, then you design it as a standalone framework which can be customized in certain predictable ways. This is how CMSes like WordPress already work. If you need to change the template and want that change to propagate to all sites, then you simply release a new version of the framework and update the sites that are based on it.
Cloning a repository is primarily meant as a tool to get multiple developers working on the same project. I think you’re going to run into many headaches in the more distant future if you try to use that model for working on several completely different projects. Without the encapsulation provided by a real framework, it’s almost certain that changes will be made to the templated sites that essentially rev-lock them, and while that’s always a risk, it’s exacerbated here by the ambiguity between modification and extension, a clear violation of the Open-Closed Principle. While that principle is specific to OOP, the general concept applies to all software.
Branches would probably make for a model that’s easier to understand, although technically in Git you can still do all of the same things with multiple repositories, albeit more awkwardly, by simply adding local ones as remotes. I’m not sure why you’d want to, but it’s possible.
It’s not good design, though. In order to keep the sites maintainable, you want a clear separation of concerns between framework/templates, content/customization, and site deployment. It sounds like you’re conflating them all and I’d urge you to reconsider before adopting a risky and bug-prone approach that depends entirely on source control. Git is great but it’s not perfect, and even when a merge has 0 conflicts it can still break your site if the changes in both repositories are significant.
4