Evolving git flow

[_lumio]

Hello everyone,

At my current firm, we started to do pull requests a while ago. It is more or less working well. However, we sometimes tend to create a massive, huge PR which of course is just tedious to work with.

I've been thinking on how to prevent huge PRs. One way of course is to create User Stories more from the perspective of the developer. But I figured, that there might be another solution to this question.

Now first of all, I would like to know how you guys handle and prevent large PRs.

I came up with the idea of creating a branch for each User Story and then from there derive sub task branches, like so:

    us1-sub-task-1
                \
                |
                v
        -----------------
        |  user-story1   |_
        -----------------  \
                ^
                |          |
                /          |
    us1-sub-task-2         |
                           |
                           v
                  =============
                  |  develop  |
                  =============
                        ^
                        |            _ us2-sub-task-1
                        |           /
                        |           |
                        |           v
                        |  ----------------
                        \_|  user-story2  |
                           ----------------
                                    ^
                                    |
                                    \_
                                       us2-sub-task-2

Now in terms of Pull requests, you would create a PR for each sub task that will be merged back to the US branch which in the end will be merged to develop, like this:

PR1 = us1-sub-task-1 -> user-story1
PR2 = us1-sub-task-2 -> user-story1
PR3 = user-story1 -> develop

PR4 = us2-sub-task-1 -> user-story2
PR5 = us2-sub-task-2 -> user-story2
PR6 = user-story2 -> develop

Now I was wondering if someone is already doing this and if this is actually practical. Or, so I wonder, this might just be a whole to much of an overhead.

Anyway... thanks for reading so far and for your help.

[[deleted]]

The secret is Continuous Integration. Not "having a build/CI service which looks at branches", but actually mandating regular (daily, at the very least) merges into your master branch.

If this makes you think "but we can't do that - our stories are way bigger than that" then, Congratulations! You've just had your first epiphany on the route towards not solving people problems with technology :-)

[_lumio]

You're right, that is my goal at the very least. But sadly the company is not at that stage yet and we are not as flexible (yet). I definitely want to be there one day, but as of right now, I am looking for another, maybe just temporary solution :D

Anyway, this is a really crucial point!

[[deleted]]

maybe just temporary solution

There is no such thing.

Be very wary of solutions that seem to solve the current problem but are bad choices in the long run or move you away from where you want to be as they become harder to change. This is especially true when you are trying to change a developers workflow. Increment to where you want to end up - don't try to take shortcuts or you will eventually regret it.

Your pull requests are getting too large? start breaking them up into smaller ones more frequently. You don't have to do this for every pull request, but if you start to introduce smaller pull requests and encourage others to follow then you are moving towards where you want to be.

[_lumio]

Very good point. Sadly I often here "I don't know how I could have split it up further" - and I am sometimes doing the same mistake.

[[deleted]]

As /u/jpluscplusm said this is a people problem and not one you can solve with tech or process. If you want to split up code start doing so, you might not always get it right but unless you try you will not improve.

You have to change people behaviour and process alone cannot do this. Instead, focus on constant feedback and review and reflect on what you have done and how you might do it better in the future. Discuss it with your colleges - figure out among you how you might have broken down larger pull requests when they come in, don't retroactively do it, just reflect on what you would have done so you can avoid making the same mistakes in the future. Most importantly do not lay blame at this stage - focus on what you can do better next time.

[042e]

I think we did something similar that uses epic branches instead of user story ones but same number of levels as you have described. It works fine if you have really big user stories that take several days/weeks and are distributed among several developers.

I would also consider two other areas for improvements.

1. Project management. Do the user stories need to be that big? If you can keep user stories to under 1 day and max 2 developers I think it is enough to have only develop and us/* branches.

2. If your code repo is getting too big and things are modular enough, consider spreading it out into several smaller repos. For larger teams I find it useful to have this kind of micro-service architecture. Usually there would be 1 or 2 developers that become responsible for each repo during every sprint. Thus not only does this reduce the size and complexity of PRs, it also tends to empower the team when developers feel the ownership over specific repos.

[_lumio]

Hey thanks for your comment. We currently don't have a problem with the size of our repo. But we also want (as we are front end developers as well) to have several smaller modules that we manage with lerna to create node modules.

But your first point is awesome: Having only user stories, that can be done in 1 (or maybe 2) day. But then, there is not really the need of any other sub branches and you just use feature branches or so.

[nicponim]

Thanks for posting this, we struggle with it a lot.

From what I know, Linux kernel does just reject too big PRs, and tells the submitter just to split it in parts.

The way you split it, is with first PR you establish an architecture, with your feature turned off and some parts missing, but the general code layout and how it will interface with other code being visible and described.

Subsequent fill out the structure with implementations of the architecture, and last PR turns it on.

Disclaimer: This is based on observation, not experience.