Best practices for Git repo structure with Bedrock, Sage, and Trellis?

bedrock
,
1

I’m curious about good Git repository structures in the Roots universe. Those of you who have used the Roots stack in production for a while, what has experience taught you to be the most useful (or least problematic) ways to organize the components of a site in Git?

I figured I’d ask since most of the threads about it here on Discourse are 6-10 years old… and some things have evolved since then. We have Trellis CLI as the recommended way to set up new projects instead of cloning the Git repos. trellis new generates everything except a theme. The roots-example-project is now deprecated.

So… in 2024, do you make separate Git repos for Trellis and Bedrock? Does it make any difference during deployment?

Do you version control a Sage-based theme or custom plugin in a separate repo and composer require it from Bedrock? Does this work if Acorn is installed at the site level? (thinking about testing during theme development).

Or do you make a sort of “monorepo” with everything (Trellis, Bedrock, Sage, custom plugins) in one Git repo so everyone always has matching versions of everything? (I don’t have a Radicle license, but that seems to be the model it’s adopted… and there’s a simplicity to it that I like.)

What works best, and how does it integrate with your day-to-day dev workflows?

Scenarios I’m wondering about:

  • Sites you own and will manage permanently.
  • Client sites that may be hosted on either Trellis or the client’s own hosting, and might be handed off entirelysomeday.
  • What happens if/when you need to collaborate with outside contractors or agencies.

reference

A few previous discussions I’ve read and found enlightening:

4 Likes
2

I keep each project in a repo with trellis bedrock sage in it. Keeps version control simple. I push each project to its own digitalocean droplet. If you want to add other devices (machines, collaborators) simply add their SSH keys. There are various configurations of this as well depending on how much access you want other to have for instance if you dont want people to have access to the trellis configuration keep it in a seperate repo and specify your bedrock/theme repo in the group_vars. These things are well documented in the trellis documentation.

2 Likes