CODEWITHSUNDEEP
gitmerge-strategy
benjimin
benjimin

Reputation: 4900

Git cherrypick and rebase onto a different history to sync a directory

Our team is using a monorepo for infracode which deploys multiple applications in two environments (production/stable and staging/unstable). To reduce friction during testing (and exploratory development) we want the merge controls (i.e., PR approval processes) to be more relaxed for the staging environment but more stringent for the production environment, which hence requires us to use separate git branches for each environment. We've factored the infracode (using kustomize overlays and flux helm templates) to isolate environment-specific customisations (like domain name prefixes) into separate locations from the shared modules (which constitute the bulk of the line count), to avoid needing any permanent divergence between the content of the two git branches.

The intention is to let changes to different applications be promoted into production/stable with independent cadences, so that an incomplete feature for one application does not hold up an an urgent fix to another application. This means that although the two branches will often have nearly identical content to each other, they will have unrelated commit histories to each other.

What git commands do we need to script together to promote the changes in just one application into production? In other words, how do you generate a pull request to sync the content in only particular directories to the corresponding paths in another branch with unrelated history, ideally while carrying across relevant commit messages?

Upvotes: -2

Views: 49

Answers (1)

benjimin
benjimin

Reputation: 4900

The monorepo structure is one of the examples promoted for Flux. Using multiple branches addresses the problem of unintended changes to production (e.g. when staging changes to shared components or kustomize base layers) as well as facilitating environment-specific merge controls, but the promotion workflows become more complicated (e.g. can no longer use simple fast-forward merges, unless all apps are ready to unstage their changes at exactly the same time). The use of environment-specific branches is contentious.

In this situation, git diff will work effectively (because the difference between content of branches is small and mostly transient) but the git rebase and cherrypick will not be entirely straightforward (because the branches soon will not have a recent common history).

It is still possible to express the diff as a patch, and apply that patch to the other branch. However, this does not retain any git messages.

Upvotes: -2

Related Questions