Our develop branch has had many feature branches merged in via PR. It also has one feature branch feature/A merged in with one change to file A merged via PR.

If I try to create a PR for feature/A for main branch, the list of changes include pretty much every branch which has been merged into develop since the last release, not just the change to A.

We understand cherry-picking is the only way solve this.

Most people cherry-pick from main to develop, but we need to do it from develop to main, so there are earlier and later PRs we need to leave out.

Cherry-picks use the commit hash, which is presumably a pointer to a commit, and we assume all commits are merges for our develop branch as we don’t use FF.

What is a commit exactly? If it’s the changes – i.e. a “diff”, then we can understand the cherry-pick command. However, if its the final state of the code after the merge (as books, diagrams and articles imply, e.g. by calling commits “snapshots” of the repo), then we are not sure how it works.

It’s clear from the excellent comments below, and the articles they link to, that commits are to be considered as snapshots, not diffs. How does cherry picking work, if commits are snapshots, in the case where my commit of feature/A on develop will contain other earlier feature branch commits which are not in main. The snapshot concept doesn’t support cherry picking as far as I can understand.

Thanks to @Romain Valeri, the answer seems to be that git commits are snapshots (i.e. the final code, so contain not only feature/A but all the unwanted features too), but cherry picking extracts just the required changes by doing some magic including diffing feature/A PR with presumably all the PRs before and after it to dynamically recreate just your specific changes. This is surprising because most sources say branches and merges are cheap in git because it stores differences, not each intermediate code snapshot.