The role of pull requests in task management
There is a common misconception that each task must must be done within the only pull request. Or, to put it more formally, it should take the lowest number of pull requests. With this approach, it becomes much more difficult to find errors and factors caused them in such “all-inclusive” pull requests. In addition, it is completely incomprehensible at what stage the development of the current feature is. Whether it is almost ready or it is only at the beginning of the implementation — even the developer of this feature is not always exactly sure.
Moreover, git conflicts will arise at every step and will be so huge that they will turn into a separate task with an absurd name “we are trying to merge the current master into my branch with 100+ commits” with a time estimation, say, five hours. And completely paralyzed git bisect will be the icing on the cake. With a marathon-like pull request with a myriad of commits, one can assert with confidence that “a bug is out there somewhere, between two masters”.
I do not like to draw analogies, but here I will try. Development of a particular feature should be similar to a chess puzzle where each individual move is a separate pull request. Without extra explanation, it’s not always clear why the rook had to be moved in a certain position, but the overall situation on the board is generally understandable. In this analogy, it is easy to notice that pull requests from the rest of the team are similar to the opponent’s moves. The figures must be moved in such a way that there is no mate (in the literal and figurative sense) and consider that opponents in the game can make a completely unexpected and even undesirable move.
In general, pull requests must be as small as possible and as atomic as possible, and then everyone will be happy. A feature can consist of a plenty of pull requests that are not necessarily consecutive.
With that said, you may remember about micromanagement of tasks. Such as, “let’s break down tasks into subtasks so that each pull request corresponds to at least a certain subtask, after all, and then everything will be okay”. However, there’re pitfalls here which make it difficult to match sub-tasks with pull requests. Moreover, it’s not always correct to talk about all types of subtasks at the project management level. And that’s why:
Even a developer doesn’t always know an entire set of steps to implement a certain feature, not to mention a manager themself. Here, as in chess, there is a clear long-term strategy but you cannot follow it with your eyes closed, it definitely must be revised after every change.
It is very important to understand the definition of “a task” at the project management level. A task like “update X-library from version 1.0.3 to 1.0.5” should not exist at all since it is not interesting to anyone, neither the developers, nor the managers, nor the customer. All tasks must be formulated exclusively from the point of view of the software user like “user stories”.
Subtasks, in turn, can really be purely technical, for example, about updating or refactoring something, writing tests, etc. And each such subtask may require a separate pull request. But speaking of the interaction between people in the project, subtasks do not exist at all. Only tasks, and that’s all!
Of course, it’s very useful to divide tasks into smaller subtasks, but each particular subtask still has to make sense for the software user. I mean, there’s a clear difference between subtasks that you actually do and those that you list in your project management tool.
And of course, this is just an example of task management principles in our team. Each company has its own well-established workflow and determines how to split and formulate tasks within a particular project.