As a promoter of the rebase faction .. that's one case where I think "merge" is correct. Since you're not changing production without going through main (I hope), every merge should just go straight through ("fast forward"?)
git checkout production
git pull --ff-only main production
git push
(at which point CI auto-deploys 'production')
(edit: have you got "rebase main onto production" the wrong way round?)
I think they must have been cherry picking changes into production. Git merge might choke on the duplicate changes, but git rebase will usually see the change from each cherry pick is already applied and skip it.
Comments
As a promoter of the rebase faction .. that's one case where I think "merge" is correct. Since you're not changing production without going through main (I hope), every merge should just go straight through ("fast forward"?)
(at which point CI auto-deploys 'production')(edit: have you got "rebase main onto production" the wrong way round?)
I think they must have been cherry picking changes into production. Git merge might choke on the duplicate changes, but git rebase will usually see the change from each cherry pick is already applied and skip it.