2

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. Sometimes the Jira ticket has a huge scope that would otherwise be a dozen different pull requests. They consider my code wrong until it's 100% complete with every single additional feature. This is for an unused API for an unreleased product, so it's not like it would break anything.

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.

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

5
  • What's tyhe quality of their code review like? Are they all just "LGTM." ?
    – Alexander
    Apr 22, 2021 at 0:05
  • No, it's not a LGTM otherwise I'd just merge it. One problem of batching everything into a single PR is if there's a conversation with one thing, it holds up the entire PR. Plus it gets confusing trying to discuss a handful of different features in a single PR. Apr 22, 2021 at 0:11
  • Oh I know that feeling well. If your colleagues don't find those points convincing, perhaps you could try to make them come to the same conclusions on their own. Put some pressure for them to merge something, but have it be held back by a minute detail.
    – Alexander
    Apr 22, 2021 at 0:15
  • do you not have a strategy to use feature branches to assemble all the functionality of a feature via smaller, one-thing-at-a-time easier-to-review PRs - and then later merge the branch into the main dev branch when the feature is complete?
    – davidbak
    Apr 22, 2021 at 0:33
  • If the entire team is used to working in a certain way, you could also try to adapt your own habits. For larger features we often make feature branches and start a draft pull request quite early on, so team members can review code before the entire feature is completed.
    – Rik D
    Apr 22, 2021 at 6:28

1 Answer 1

7

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.

1
  • That's a pretty smart strategy to just make an epic branch and then your own feature branches with your own subtacks. Thanks! Apr 22, 2021 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.