The team I am working with frequently create a feature branch, do some work on it, create a PR and merge this feature branch back to develop, do some more work on it, do another PR and merge it back to develop. Develop moves along independently from this, so the two merges are not together in the history.

The devs say this is so they can “revert the changes easily”.

However, I would assume that cherry picking and reverting is harder, as for a given feature there are multiple commits.

Looking at git flow tutorials and guides, there is no mention of this scenario – I can only find examples where a feature branch has a single PR and merge at the end of it.

What are the pros/cons of this method, vs creating a new branch for the second commit?

The reason the devs dont want to create a new branch for the second commit is because each of our feature branches has to have a jira ticket, and they dont want to have to create a new jira ticket.

If only having one PR per feature branch is best practice, what argument can I use to persuade the devs to do the extra work?

Ive never had to cherry pick features where there are multiple merges for each feature, so not sure if there are any drawbacks.