devs work against a dev branch, creating feature branches, then merging them back into the dev branch via devops PRs. Any merged PRs get built and deployed to the dev server immediately.
In this case, the feature branch is a child of the dev branch, and result is merged back into dev branch.
We have a test branch, uat branch, prod branch etc, and each kicks off a different pipeline to build for a specific environment (As Adobe AEM cloud requires you rebuild from source for each env unfortunately).
Currently, we force push whatever is on dev to test, then force push onto UAT etc.
This is bad.
We only want to put some PRs (feature branches) onto test to form our release candidate, which then gets pushed to the other evs as testing progresses.
Presumably the options are
a) cherry pick the PR merge commits. b) merge?
We seen advice that merge is better than cherry pick, but in this case we would be trying to merge a feature branch with a dev branch parent to the test branch - they are different parents.
A feature branch might consist of say 5 commits, plus an extra commit when it was merged back into the dev branch (assuming squashed). We don't do rebase. Sometimes the devs squash merge.
If we want to cherry pick, it uses a commit. If we pick the last commit of the feature branch (5th commit), will this include the changes in commit 1 to 4? OR do we need to pick the 6th commit, the one where it was merged into dev branch?
Presumably if we use cherry picking, we have the issue that if file A was created in feature branch/PR 1, and modified in feature branch/PR 2, and we try to cherrypick PR2, its going to fail, with no easy solution (other than to also take PR1). Presumably this is a common issue with creating a release candidate from a bunch of PRs?
