Note that without concrete numbers and sizes, it’s hard to give you an objective judgment on who is wrong and who is right. Maybe their tickets are too big, maybe you’re making your changesets too small. I can’t objectively tell that from your possibly subjective explanation.

However, there are ways you can work around this issue so that both of you mostly get what you want.

I’m working in a team that won’t approve my pull requests until the entire Jira ticket is all included in the pull request.

This specific approach is correct. Half-tickets are generally not complete changesets.

However…

Sometimes the Jira ticket has a huge scope that would otherwise be a dozen different pull requests.

The above advice implicitly assumes that the Jira ticket has been broken down into a reasonably sized changeset. If that is not the case, what you should tackle here isn’t that the team should allow half-tickets to be pull requested, but rather for Jira tickets to be portioned more reasonably.

Note that I’m taking you at your word here. Without concrete details, I can’t differentiate between a case where a ticket is MASSIVE and you are trying to have reasonable changesets pulled (which puts you in the right), or where a ticket is reasonable and you are trying to have tiny changesets pulled (which puts you in the wrong).

This is for an unused API for an unreleased product, so it’s not like it would break anything.

It’s a bad idea to start changing your general guidelines just because “this change won’t break anything”. The point of having general guidelines is to have consistency and balance, as opposed to custom rules for custom situations.

That doesn’t mean that the current guideline is correct, the ticket might be too overloaded; but the better approach here is to tackle that on principle (if you want to), instead of arguing why your specific ticket happens to not run the risk of breaking something.

You can’t fight a bad approach by using another bad approach.

At other places I’ve worked, we’ve found that small pull requests are better; ideally a pull request only does one thing. You can always make multiple pull requests.

Again, lack of concrete numbers leads to lack of judgment. Things can be too small, or they can be too large. You clearly want them to be smaller, but it’s unclear whether you want them to be too small, and whether they originally were too large.

Smaller pull requests are indeed better, but very commonly I only open one PR per task, unless there is an unexpected change/bugfix that needs to happen after the first PR has already been completed.

Because of your “you can always make multiple pull requests” statement, it begins to feel to me like you’re almost trying to use PRs the way you should commit/push to the origin Git repo (i.e. once a day at least, preferably per small and self-contained change).
The general advice to commit frequently does not entail pull requests.

But again, without concrete numbers, I have no idea whether you’re trying to PR daily on a week long ticket, or are trying to PR weekly on a months-long ticket. That very much makes a difference.

Am I wrong, or if not, how do you recommend I convince my team to prefer small pull requests?

Do not focus on the size of the pull request. Focus on the size of the ticket. The idea that PRs should generally match the content of the ticket is correct and should not be altered.

One more thing to mention is that even if the tickets are genuinely too large, and this will not change no matter how much you try, nothing is stopping you from further subdividing the changeset into subtickets of their own, and perform your own sub-feature-branching to keep it better managed.

Then you simply PR them into your main feature branch (instead of master), and when the ticket is complete, you PR your main feature branch to master.

This means that you can subdivide your work as you please without the rest of the team needing to know/care about how you do it. At the end of the ticket, you just PR into master like they expect you to, and what happened before it is not something they’re dictating.

This was done at an old project of mine. Jira tickets were created by the product owner or the non-development project manager, and it was often a massive conflation of features. There was no way to get this system to change, so what me and a handful of consultants did was subdivide the work.

• We treated the ticket as an epic. We created subtasks, which we considered as the real “tickets”.
• For the epic, we branched off from master into what I’ll call the epic branch.
• For each subtask, which we treated as a ticket, we branched off from the epic branch into a “real” feature branch.
• When the epic was completed, we PRed it into master.

Was this an ideal solution? No.
Would it have been better to have properly scoped tickets to begin with? Yes.

But the sub-branching was already helping the developers keep their sanity and keep things better organized than management thought things needed to be.