How to ensure that release tags are uniformly created throughout a cohort of closely-related Git repositories?

Working as part of the release team for a sprawling open source project that uses dozens of Git repositories, I regularly run into situations where one or more of the satellite repositories are missing their own matching tag for a new release version published at the primary repo. My initial attempts to curb this phenomenon with more detailed release process documentation and checklist style workflows have sadly failed to move the needle on this, so I'm soliciting advice on how best to approach the matter programmatically to have the creation of a new tagged release in the top-most repository in the hierarchy create a condition in all the others for the next commit pushed to include an identically named tag. I haven't used Git hooks very much, but this would seem like a problem they're well-suited for. What would that look like in practice? I worry, though, that just like my documentation and workflow approach, anything which can be easily ignored or bypassed by other contributors will inevitably become so. Perhaps then utilizing the CI/CD functions at either GitHub or GitLab¹ and making them obligatory for all collaborators would produce more reliable results? I feel like I'm in a sort of liminal space on this topic in which I know just a bit too much to leap blindly at the first plausible solution but not nearly enough to perform an exhaustive evaluation of the ecosystem and ascertain which approach is truly best for this use case. Any guidance is deeply appreciated. ¹ We use a self-hosted GitLab instance internally but all the repositories there are mirrored on GitHub to facilitate participation, so solutions based on either platform's capabilities are feasible.

Jun 15, 2025 - 00:50

Working as part of the release team for a sprawling open source project that uses dozens of Git repositories, I regularly run into situations where one or more of the satellite repositories are missing their own matching tag for a new release version published at the primary repo. My initial attempts to curb this phenomenon with more detailed release process documentation and checklist style workflows have sadly failed to move the needle on this, so I'm soliciting advice on how best to approach the matter programmatically to have the creation of a new tagged release in the top-most repository in the hierarchy create a condition in all the others for the next commit pushed to include an identically named tag.

I haven't used Git hooks very much, but this would seem like a problem they're well-suited for. What would that look like in practice? I worry, though, that just like my documentation and workflow approach, anything which can be easily ignored or bypassed by other contributors will inevitably become so. Perhaps then utilizing the CI/CD functions at either GitHub or GitLab¹ and making them obligatory for all collaborators would produce more reliable results?

I feel like I'm in a sort of liminal space on this topic in which I know just a bit too much to leap blindly at the first plausible solution but not nearly enough to perform an exhaustive evaluation of the ecosystem and ascertain which approach is truly best for this use case. Any guidance is deeply appreciated.

¹ We use a self-hosted GitLab instance internally but all the repositories there are mirrored on GitHub to facilitate participation, so solutions based on either platform's capabilities are feasible.